* [PATCH v5 0/6] ARM: hisi: Add initial support including clock driver for Hi3519 soc.
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
Hello,
Hi3519 soc is mainly used for ip camera and sport DV solutions. This patchset adds initial support
for Hi3519 soc. It includes clock driver, arch configuration, debug uart configuration and device tree.
It has been tested on hi3519 reference board.
Any comments will be appreciated!
Thanks!
Change Log
----------
v5:
-Adjust clock and reset controller driver code
v4:
-Rebase to v4.4-rc7
-Divide patches according to Rob's comments
-Add spi nodes in hi3519-demb.dts
v3:
-Rebase to v4.4-rc4
-Adjust according to Arnd's comments
-Remove ARCH_HI3519, using ARCH_HISI directly
v2:
-Rebase to v4.4-rc3
-Put dt-binding doc and header file in a separate patch.
-Delete unused clocks definitions.
-Adjust the ARCH_xxx order in Kconfig file
-Rename ARCH_HI3xxx to ARCH_36xx
Jiancheng Xue (6):
clk: hisilicon: add CRG driver for hi3519 soc
ARM: hisi: add compatible string for Hi3519 soc
ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
ARM: debug: add hi3519 debug uart
mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
ARM: dts: add dts files for Hi3519
Jiancheng Xue (6):
clk: hisilicon: add CRG driver for hi3519 soc
ARM: hisi: add compatible string for Hi3519 soc
ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
ARM: debug: add hi3519 debug uart
mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
ARM: dts: add dts files for Hi3519
.../devicetree/bindings/clock/hi3519-crg.txt | 46 ++++++
Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++
arch/arm/Kconfig.debug | 10 ++
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/hi3519-demb.dts | 42 +++++
arch/arm/boot/dts/hi3519.dtsi | 175 +++++++++++++++++++++
arch/arm/configs/hisi_defconfig | 1 +
arch/arm/mach-hisi/hisilicon.c | 23 +--
drivers/clk/hisilicon/Kconfig | 7 +
drivers/clk/hisilicon/Makefile | 2 +
drivers/clk/hisilicon/clk-hi3519.c | 105 +++++++++++++
drivers/clk/hisilicon/reset.c | 129 +++++++++++++++
drivers/clk/hisilicon/reset.h | 32 ++++
include/dt-bindings/clock/hi3519-clock.h | 43 +++++
14 files changed, 612 insertions(+), 19 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
create mode 100644 arch/arm/boot/dts/hi3519.dtsi
create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
create mode 100644 drivers/clk/hisilicon/reset.c
create mode 100644 drivers/clk/hisilicon/reset.h
create mode 100644 include/dt-bindings/clock/hi3519-clock.h
--
1.9.1
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 0/6] ARM: hisi: Add initial support including clock driver for Hi3519 soc.
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
Hello,
Hi3519 soc is mainly used for ip camera and sport DV solutions. This patchset adds initial support
for Hi3519 soc. It includes clock driver, arch configuration, debug uart configuration and device tree.
It has been tested on hi3519 reference board.
Any comments will be appreciated!
Thanks!
Change Log
----------
v5:
-Adjust clock and reset controller driver code
v4:
-Rebase to v4.4-rc7
-Divide patches according to Rob's comments
-Add spi nodes in hi3519-demb.dts
v3:
-Rebase to v4.4-rc4
-Adjust according to Arnd's comments
-Remove ARCH_HI3519, using ARCH_HISI directly
v2:
-Rebase to v4.4-rc3
-Put dt-binding doc and header file in a separate patch.
-Delete unused clocks definitions.
-Adjust the ARCH_xxx order in Kconfig file
-Rename ARCH_HI3xxx to ARCH_36xx
Jiancheng Xue (6):
clk: hisilicon: add CRG driver for hi3519 soc
ARM: hisi: add compatible string for Hi3519 soc
ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
ARM: debug: add hi3519 debug uart
mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
ARM: dts: add dts files for Hi3519
Jiancheng Xue (6):
clk: hisilicon: add CRG driver for hi3519 soc
ARM: hisi: add compatible string for Hi3519 soc
ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
ARM: debug: add hi3519 debug uart
mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
ARM: dts: add dts files for Hi3519
.../devicetree/bindings/clock/hi3519-crg.txt | 46 ++++++
Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++
arch/arm/Kconfig.debug | 10 ++
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/hi3519-demb.dts | 42 +++++
arch/arm/boot/dts/hi3519.dtsi | 175 +++++++++++++++++++++
arch/arm/configs/hisi_defconfig | 1 +
arch/arm/mach-hisi/hisilicon.c | 23 +--
drivers/clk/hisilicon/Kconfig | 7 +
drivers/clk/hisilicon/Makefile | 2 +
drivers/clk/hisilicon/clk-hi3519.c | 105 +++++++++++++
drivers/clk/hisilicon/reset.c | 129 +++++++++++++++
drivers/clk/hisilicon/reset.h | 32 ++++
include/dt-bindings/clock/hi3519-clock.h | 43 +++++
14 files changed, 612 insertions(+), 19 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
create mode 100644 arch/arm/boot/dts/hi3519.dtsi
create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
create mode 100644 drivers/clk/hisilicon/reset.c
create mode 100644 drivers/clk/hisilicon/reset.h
create mode 100644 include/dt-bindings/clock/hi3519-clock.h
--
1.9.1
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 0/6] ARM: hisi: Add initial support including clock driver for Hi3519 soc.
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Hi3519 soc is mainly used for ip camera and sport DV solutions. This patchset adds initial support
for Hi3519 soc. It includes clock driver, arch configuration, debug uart configuration and device tree.
It has been tested on hi3519 reference board.
Any comments will be appreciated!
Thanks!
Change Log
----------
v5:
-Adjust clock and reset controller driver code
v4:
-Rebase to v4.4-rc7
-Divide patches according to Rob's comments
-Add spi nodes in hi3519-demb.dts
v3:
-Rebase to v4.4-rc4
-Adjust according to Arnd's comments
-Remove ARCH_HI3519, using ARCH_HISI directly
v2:
-Rebase to v4.4-rc3
-Put dt-binding doc and header file in a separate patch.
-Delete unused clocks definitions.
-Adjust the ARCH_xxx order in Kconfig file
-Rename ARCH_HI3xxx to ARCH_36xx
Jiancheng Xue (6):
clk: hisilicon: add CRG driver for hi3519 soc
ARM: hisi: add compatible string for Hi3519 soc
ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
ARM: debug: add hi3519 debug uart
mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
ARM: dts: add dts files for Hi3519
Jiancheng Xue (6):
clk: hisilicon: add CRG driver for hi3519 soc
ARM: hisi: add compatible string for Hi3519 soc
ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
ARM: debug: add hi3519 debug uart
mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
ARM: dts: add dts files for Hi3519
.../devicetree/bindings/clock/hi3519-crg.txt | 46 ++++++
Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++
arch/arm/Kconfig.debug | 10 ++
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/hi3519-demb.dts | 42 +++++
arch/arm/boot/dts/hi3519.dtsi | 175 +++++++++++++++++++++
arch/arm/configs/hisi_defconfig | 1 +
arch/arm/mach-hisi/hisilicon.c | 23 +--
drivers/clk/hisilicon/Kconfig | 7 +
drivers/clk/hisilicon/Makefile | 2 +
drivers/clk/hisilicon/clk-hi3519.c | 105 +++++++++++++
drivers/clk/hisilicon/reset.c | 129 +++++++++++++++
drivers/clk/hisilicon/reset.h | 32 ++++
include/dt-bindings/clock/hi3519-clock.h | 43 +++++
14 files changed, 612 insertions(+), 19 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
create mode 100644 arch/arm/boot/dts/hi3519.dtsi
create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
create mode 100644 drivers/clk/hisilicon/reset.c
create mode 100644 drivers/clk/hisilicon/reset.h
create mode 100644 include/dt-bindings/clock/hi3519-clock.h
--
1.9.1
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-08 2:16 ` Jiancheng Xue
(?)
@ 2016-01-08 2:16 ` Jiancheng Xue
-1 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
The CRG(Clock and Reset Generator) block provides clock
and reset signals for other modules in hi3519 soc.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
.../devicetree/bindings/clock/hi3519-crg.txt | 46 ++++++++
drivers/clk/hisilicon/Kconfig | 7 ++
drivers/clk/hisilicon/Makefile | 2 +
drivers/clk/hisilicon/clk-hi3519.c | 105 +++++++++++++++++
drivers/clk/hisilicon/reset.c | 129 +++++++++++++++++++++
drivers/clk/hisilicon/reset.h | 32 +++++
include/dt-bindings/clock/hi3519-clock.h | 43 +++++++
7 files changed, 364 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
create mode 100644 drivers/clk/hisilicon/reset.c
create mode 100644 drivers/clk/hisilicon/reset.h
create mode 100644 include/dt-bindings/clock/hi3519-clock.h
diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
new file mode 100644
index 0000000..2d23950
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
@@ -0,0 +1,46 @@
+* Hisilicon Hi3519 Clock and Reset Generator(CRG)
+
+The Hi3519 CRG module provides clock and reset signals to various
+controllers within the SoC.
+
+This binding uses the following bindings:
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+ Documentation/devicetree/bindings/reset/reset.txt
+
+Required Properties:
+
+- compatible: should be one of the following.
+ - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in <dt-bindings/clock/hi3519-clock.h>.
+
+- #reset-cells: should be 2.
+
+A reset signal can be controlled by writing a bit register in the CRG module.
+The reset specifier consists of two cells. The first cell represents the
+register offset relative to the base address. The second cell represents the
+bit index in the register.
+
+Example: CRG nodes
+CRG: clock-reset-controller@12010000 {
+ compatible = "hisilicon,hi3519-crg";
+ reg = <0x12010000 0x10000>;
+ #clock-cells = <1>;
+ #reset-cells = <2>;
+};
+
+Example: consumer nodes
+i2c0: i2c@12110000 {
+ compatible = "hisilicon,hi3519-i2c";
+ reg = <0x12110000 0x1000>;
+ clocks = <&CRG HI3519_I2C0_RST>;*/
+ resets = <&CRG 0xe4 0>;
+};
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index e434854..b6baebf 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -1,3 +1,10 @@
+config COMMON_CLK_HI3519
+ tristate "Clock Driver for Hi3519"
+ depends on ARCH_HISI
+ default y
+ help
+ Build the clock driver for hi3519.
+
config COMMON_CLK_HI6220
bool "Hi6220 Clock Driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 74dba31..3f57b09 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -4,8 +4,10 @@
obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o
+obj-$(CONFIG_RESET_CONTROLLER) += reset.o
obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o
obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o
obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
obj-$(CONFIG_COMMON_CLK_HI6220) += clk-hi6220.o
obj-$(CONFIG_STUB_CLK_HI6220) += clk-hi6220-stub.o
+obj-$(CONFIG_COMMON_CLK_HI3519) += clk-hi3519.o
diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
new file mode 100644
index 0000000..72d3a7b0
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3519.c
@@ -0,0 +1,105 @@
+/*
+ * Hi3519 Clock Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <dt-bindings/clock/hi3519-clock.h>
+#include <linux/delay.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include "clk.h"
+#include "reset.h"
+
+#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
+#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
+#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
+#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
+#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
+#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
+#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
+#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
+#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
+#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
+
+#define HI3519_NR_CLKS 128
+
+static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
+ { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
+ { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
+ { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
+ { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
+ { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
+ { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
+ { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
+ { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
+ { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
+ { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
+};
+
+static const char *fmc_mux_p[] __initconst = {
+ "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
+static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
+static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
+ { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
+ CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
+};
+
+static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
+ /* fmc */
+ { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
+ CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
+ /* uart */
+ { HI3519_UART0_CLK, "clk_uart0", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
+ { HI3519_UART1_CLK, "clk_uart1", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
+ { HI3519_UART2_CLK, "clk_uart2", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
+ { HI3519_UART3_CLK, "clk_uart3", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
+ { HI3519_UART4_CLK, "clk_uart4", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
+ { HI3519_SPI0_CLK, "clk_spi0", "50m",
+ CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
+ { HI3519_SPI1_CLK, "clk_spi1", "50m",
+ CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
+ { HI3519_SPI2_CLK, "clk_spi2", "50m",
+ CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
+};
+
+static void __init hi3519_clk_init(struct device_node *np)
+{
+ struct hisi_clock_data *clk_data;
+
+
+ clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
+ if (!clk_data)
+ return;
+
+ hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
+ ARRAY_SIZE(hi3519_fixed_rate_clks),
+ clk_data);
+ hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
+ clk_data);
+ hisi_clk_register_gate(hi3519_gate_clks,
+ ARRAY_SIZE(hi3519_gate_clks), clk_data);
+
+ hisi_reset_init(np);
+}
+
+CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
new file mode 100644
index 0000000..f11561c
--- /dev/null
+++ b/drivers/clk/hisilicon/reset.c
@@ -0,0 +1,129 @@
+/*
+ * Hisilicon Reset Controller Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+#define HISI_RESET_BIT_MASK 0x1f
+#define HISI_RESET_OFFSET_SHIFT 8
+#define HISI_RESET_OFFSET_MASK 0xffff00
+
+struct hisi_reset_controller {
+ spinlock_t lock;
+ void __iomem *membase;
+ struct reset_controller_dev rcdev;
+};
+
+
+#define to_hisi_reset_controller(rcdev) \
+ container_of(rcdev, struct hisi_reset_controller, rcdev)
+
+static int hisi_reset_of_xlate(struct reset_controller_dev *rcdev,
+ const struct of_phandle_args *reset_spec)
+{
+ u32 offset;
+ u8 bit;
+
+ if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
+ return -EINVAL;
+
+ offset = (reset_spec->args[0] << HISI_RESET_OFFSET_SHIFT)
+ & HISI_RESET_OFFSET_MASK;
+ bit = reset_spec->args[1] & HISI_RESET_BIT_MASK;
+ return (offset | bit);
+}
+
+static int hisi_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
+ unsigned long flags;
+ u32 offset, reg;
+ u8 bit;
+
+ offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
+ bit = id & HISI_RESET_BIT_MASK;
+
+ spin_lock_irqsave(&rstc->lock, flags);
+
+ reg = readl(rstc->membase + offset);
+ writel(reg | BIT(bit), rstc->membase + offset);
+
+ spin_unlock_irqrestore(&rstc->lock, flags);
+
+ return 0;
+}
+
+static int hisi_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
+ unsigned long flags;
+ u32 offset, reg;
+ u8 bit;
+
+ offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
+ bit = id & HISI_RESET_BIT_MASK;
+
+ spin_lock_irqsave(&rstc->lock, flags);
+
+ reg = readl(rstc->membase + offset);
+ writel(reg & ~BIT(bit), rstc->membase + offset);
+
+ spin_unlock_irqrestore(&rstc->lock, flags);
+
+ return 0;
+}
+
+static struct reset_control_ops hisi_reset_ops = {
+ .assert = hisi_reset_assert,
+ .deassert = hisi_reset_deassert,
+};
+
+int __init hisi_reset_init(struct device_node *np)
+{
+ struct hisi_reset_controller *rstc;
+
+ rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
+ if (!rstc)
+ return -ENOMEM;
+
+ rstc->membase = of_iomap(np, 0);
+ if (!rstc->membase)
+ return -EINVAL;
+
+ spin_lock_init(&rstc->lock);
+
+ rstc->rcdev.owner = THIS_MODULE;
+ rstc->rcdev.ops = &hisi_reset_ops;
+ rstc->rcdev.of_node = np;
+ rstc->rcdev.of_reset_n_cells = 2;
+ rstc->rcdev.of_xlate = hisi_reset_of_xlate;
+
+ return reset_controller_register(&rstc->rcdev);
+}
diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
new file mode 100644
index 0000000..37856089
--- /dev/null
+++ b/drivers/clk/hisilicon/reset.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __HISI_RESET_H
+#define __HISI_RESET_H
+
+#include <linux/of.h>
+
+#ifdef CONFIG_RESET_CONTROLLER
+int __init hisi_reset_init(struct device_node *np);
+#else
+static inline int __init hisi_reset_init(struct device_node *np)
+{
+ return 0;
+}
+#endif
+
+#endif /* __HISI_RESET_H */
diff --git a/include/dt-bindings/clock/hi3519-clock.h b/include/dt-bindings/clock/hi3519-clock.h
new file mode 100644
index 0000000..1e4a3c1
--- /dev/null
+++ b/include/dt-bindings/clock/hi3519-clock.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __DTS_HI3519_CLOCK_H
+#define __DTS_HI3519_CLOCK_H
+
+#define HI3519_FIXED_3M 1
+#define HI3519_FMC_CLK 2
+#define HI3519_USB2_BUS_CLK 3
+#define HI3519_USB2_PORT_CLK 4
+#define HI3519_USB3_CLK 5
+#define HI3519_ETH_PHY_CLK 6
+#define HI3519_ETH_MAC_CLK 7
+#define HI3519_ETH_MACIF_CLK 8
+#define HI3519_PWM_CLK 9
+#define HI3519_DMA_CLK 10
+#define HI3519_SPI0_CLK 11
+#define HI3519_SPI1_CLK 12
+#define HI3519_SPI2_CLK 13
+#define HI3519_IR_CLK 14
+#define HI3519_UART0_CLK 15
+#define HI3519_UART1_CLK 16
+#define HI3519_UART2_CLK 17
+#define HI3519_UART3_CLK 18
+#define HI3519_UART4_CLK 19
+
+#define HI3519_EXT_CLKS 19
+
+#endif /* __DTS_HI3519_CLOCK_H */
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
The CRG(Clock and Reset Generator) block provides clock
and reset signals for other modules in hi3519 soc.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
.../devicetree/bindings/clock/hi3519-crg.txt | 46 ++++++++
drivers/clk/hisilicon/Kconfig | 7 ++
drivers/clk/hisilicon/Makefile | 2 +
drivers/clk/hisilicon/clk-hi3519.c | 105 +++++++++++++++++
drivers/clk/hisilicon/reset.c | 129 +++++++++++++++++++++
drivers/clk/hisilicon/reset.h | 32 +++++
include/dt-bindings/clock/hi3519-clock.h | 43 +++++++
7 files changed, 364 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
create mode 100644 drivers/clk/hisilicon/reset.c
create mode 100644 drivers/clk/hisilicon/reset.h
create mode 100644 include/dt-bindings/clock/hi3519-clock.h
diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
new file mode 100644
index 0000000..2d23950
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
@@ -0,0 +1,46 @@
+* Hisilicon Hi3519 Clock and Reset Generator(CRG)
+
+The Hi3519 CRG module provides clock and reset signals to various
+controllers within the SoC.
+
+This binding uses the following bindings:
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+ Documentation/devicetree/bindings/reset/reset.txt
+
+Required Properties:
+
+- compatible: should be one of the following.
+ - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in <dt-bindings/clock/hi3519-clock.h>.
+
+- #reset-cells: should be 2.
+
+A reset signal can be controlled by writing a bit register in the CRG module.
+The reset specifier consists of two cells. The first cell represents the
+register offset relative to the base address. The second cell represents the
+bit index in the register.
+
+Example: CRG nodes
+CRG: clock-reset-controller@12010000 {
+ compatible = "hisilicon,hi3519-crg";
+ reg = <0x12010000 0x10000>;
+ #clock-cells = <1>;
+ #reset-cells = <2>;
+};
+
+Example: consumer nodes
+i2c0: i2c@12110000 {
+ compatible = "hisilicon,hi3519-i2c";
+ reg = <0x12110000 0x1000>;
+ clocks = <&CRG HI3519_I2C0_RST>;*/
+ resets = <&CRG 0xe4 0>;
+};
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index e434854..b6baebf 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -1,3 +1,10 @@
+config COMMON_CLK_HI3519
+ tristate "Clock Driver for Hi3519"
+ depends on ARCH_HISI
+ default y
+ help
+ Build the clock driver for hi3519.
+
config COMMON_CLK_HI6220
bool "Hi6220 Clock Driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 74dba31..3f57b09 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -4,8 +4,10 @@
obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o
+obj-$(CONFIG_RESET_CONTROLLER) += reset.o
obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o
obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o
obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
obj-$(CONFIG_COMMON_CLK_HI6220) += clk-hi6220.o
obj-$(CONFIG_STUB_CLK_HI6220) += clk-hi6220-stub.o
+obj-$(CONFIG_COMMON_CLK_HI3519) += clk-hi3519.o
diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
new file mode 100644
index 0000000..72d3a7b0
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3519.c
@@ -0,0 +1,105 @@
+/*
+ * Hi3519 Clock Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <dt-bindings/clock/hi3519-clock.h>
+#include <linux/delay.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include "clk.h"
+#include "reset.h"
+
+#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
+#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
+#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
+#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
+#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
+#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
+#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
+#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
+#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
+#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
+
+#define HI3519_NR_CLKS 128
+
+static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
+ { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
+ { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
+ { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
+ { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
+ { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
+ { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
+ { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
+ { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
+ { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
+ { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
+};
+
+static const char *fmc_mux_p[] __initconst = {
+ "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
+static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
+static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
+ { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
+ CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
+};
+
+static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
+ /* fmc */
+ { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
+ CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
+ /* uart */
+ { HI3519_UART0_CLK, "clk_uart0", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
+ { HI3519_UART1_CLK, "clk_uart1", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
+ { HI3519_UART2_CLK, "clk_uart2", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
+ { HI3519_UART3_CLK, "clk_uart3", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
+ { HI3519_UART4_CLK, "clk_uart4", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
+ { HI3519_SPI0_CLK, "clk_spi0", "50m",
+ CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
+ { HI3519_SPI1_CLK, "clk_spi1", "50m",
+ CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
+ { HI3519_SPI2_CLK, "clk_spi2", "50m",
+ CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
+};
+
+static void __init hi3519_clk_init(struct device_node *np)
+{
+ struct hisi_clock_data *clk_data;
+
+
+ clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
+ if (!clk_data)
+ return;
+
+ hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
+ ARRAY_SIZE(hi3519_fixed_rate_clks),
+ clk_data);
+ hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
+ clk_data);
+ hisi_clk_register_gate(hi3519_gate_clks,
+ ARRAY_SIZE(hi3519_gate_clks), clk_data);
+
+ hisi_reset_init(np);
+}
+
+CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
new file mode 100644
index 0000000..f11561c
--- /dev/null
+++ b/drivers/clk/hisilicon/reset.c
@@ -0,0 +1,129 @@
+/*
+ * Hisilicon Reset Controller Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+#define HISI_RESET_BIT_MASK 0x1f
+#define HISI_RESET_OFFSET_SHIFT 8
+#define HISI_RESET_OFFSET_MASK 0xffff00
+
+struct hisi_reset_controller {
+ spinlock_t lock;
+ void __iomem *membase;
+ struct reset_controller_dev rcdev;
+};
+
+
+#define to_hisi_reset_controller(rcdev) \
+ container_of(rcdev, struct hisi_reset_controller, rcdev)
+
+static int hisi_reset_of_xlate(struct reset_controller_dev *rcdev,
+ const struct of_phandle_args *reset_spec)
+{
+ u32 offset;
+ u8 bit;
+
+ if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
+ return -EINVAL;
+
+ offset = (reset_spec->args[0] << HISI_RESET_OFFSET_SHIFT)
+ & HISI_RESET_OFFSET_MASK;
+ bit = reset_spec->args[1] & HISI_RESET_BIT_MASK;
+ return (offset | bit);
+}
+
+static int hisi_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
+ unsigned long flags;
+ u32 offset, reg;
+ u8 bit;
+
+ offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
+ bit = id & HISI_RESET_BIT_MASK;
+
+ spin_lock_irqsave(&rstc->lock, flags);
+
+ reg = readl(rstc->membase + offset);
+ writel(reg | BIT(bit), rstc->membase + offset);
+
+ spin_unlock_irqrestore(&rstc->lock, flags);
+
+ return 0;
+}
+
+static int hisi_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
+ unsigned long flags;
+ u32 offset, reg;
+ u8 bit;
+
+ offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
+ bit = id & HISI_RESET_BIT_MASK;
+
+ spin_lock_irqsave(&rstc->lock, flags);
+
+ reg = readl(rstc->membase + offset);
+ writel(reg & ~BIT(bit), rstc->membase + offset);
+
+ spin_unlock_irqrestore(&rstc->lock, flags);
+
+ return 0;
+}
+
+static struct reset_control_ops hisi_reset_ops = {
+ .assert = hisi_reset_assert,
+ .deassert = hisi_reset_deassert,
+};
+
+int __init hisi_reset_init(struct device_node *np)
+{
+ struct hisi_reset_controller *rstc;
+
+ rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
+ if (!rstc)
+ return -ENOMEM;
+
+ rstc->membase = of_iomap(np, 0);
+ if (!rstc->membase)
+ return -EINVAL;
+
+ spin_lock_init(&rstc->lock);
+
+ rstc->rcdev.owner = THIS_MODULE;
+ rstc->rcdev.ops = &hisi_reset_ops;
+ rstc->rcdev.of_node = np;
+ rstc->rcdev.of_reset_n_cells = 2;
+ rstc->rcdev.of_xlate = hisi_reset_of_xlate;
+
+ return reset_controller_register(&rstc->rcdev);
+}
diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
new file mode 100644
index 0000000..37856089
--- /dev/null
+++ b/drivers/clk/hisilicon/reset.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __HISI_RESET_H
+#define __HISI_RESET_H
+
+#include <linux/of.h>
+
+#ifdef CONFIG_RESET_CONTROLLER
+int __init hisi_reset_init(struct device_node *np);
+#else
+static inline int __init hisi_reset_init(struct device_node *np)
+{
+ return 0;
+}
+#endif
+
+#endif /* __HISI_RESET_H */
diff --git a/include/dt-bindings/clock/hi3519-clock.h b/include/dt-bindings/clock/hi3519-clock.h
new file mode 100644
index 0000000..1e4a3c1
--- /dev/null
+++ b/include/dt-bindings/clock/hi3519-clock.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __DTS_HI3519_CLOCK_H
+#define __DTS_HI3519_CLOCK_H
+
+#define HI3519_FIXED_3M 1
+#define HI3519_FMC_CLK 2
+#define HI3519_USB2_BUS_CLK 3
+#define HI3519_USB2_PORT_CLK 4
+#define HI3519_USB3_CLK 5
+#define HI3519_ETH_PHY_CLK 6
+#define HI3519_ETH_MAC_CLK 7
+#define HI3519_ETH_MACIF_CLK 8
+#define HI3519_PWM_CLK 9
+#define HI3519_DMA_CLK 10
+#define HI3519_SPI0_CLK 11
+#define HI3519_SPI1_CLK 12
+#define HI3519_SPI2_CLK 13
+#define HI3519_IR_CLK 14
+#define HI3519_UART0_CLK 15
+#define HI3519_UART1_CLK 16
+#define HI3519_UART2_CLK 17
+#define HI3519_UART3_CLK 18
+#define HI3519_UART4_CLK 19
+
+#define HI3519_EXT_CLKS 19
+
+#endif /* __DTS_HI3519_CLOCK_H */
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: linux-arm-kernel
The CRG(Clock and Reset Generator) block provides clock
and reset signals for other modules in hi3519 soc.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
.../devicetree/bindings/clock/hi3519-crg.txt | 46 ++++++++
drivers/clk/hisilicon/Kconfig | 7 ++
drivers/clk/hisilicon/Makefile | 2 +
drivers/clk/hisilicon/clk-hi3519.c | 105 +++++++++++++++++
drivers/clk/hisilicon/reset.c | 129 +++++++++++++++++++++
drivers/clk/hisilicon/reset.h | 32 +++++
include/dt-bindings/clock/hi3519-clock.h | 43 +++++++
7 files changed, 364 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
create mode 100644 drivers/clk/hisilicon/reset.c
create mode 100644 drivers/clk/hisilicon/reset.h
create mode 100644 include/dt-bindings/clock/hi3519-clock.h
diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
new file mode 100644
index 0000000..2d23950
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
@@ -0,0 +1,46 @@
+* Hisilicon Hi3519 Clock and Reset Generator(CRG)
+
+The Hi3519 CRG module provides clock and reset signals to various
+controllers within the SoC.
+
+This binding uses the following bindings:
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+ Documentation/devicetree/bindings/reset/reset.txt
+
+Required Properties:
+
+- compatible: should be one of the following.
+ - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in <dt-bindings/clock/hi3519-clock.h>.
+
+- #reset-cells: should be 2.
+
+A reset signal can be controlled by writing a bit register in the CRG module.
+The reset specifier consists of two cells. The first cell represents the
+register offset relative to the base address. The second cell represents the
+bit index in the register.
+
+Example: CRG nodes
+CRG: clock-reset-controller at 12010000 {
+ compatible = "hisilicon,hi3519-crg";
+ reg = <0x12010000 0x10000>;
+ #clock-cells = <1>;
+ #reset-cells = <2>;
+};
+
+Example: consumer nodes
+i2c0: i2c at 12110000 {
+ compatible = "hisilicon,hi3519-i2c";
+ reg = <0x12110000 0x1000>;
+ clocks = <&CRG HI3519_I2C0_RST>;*/
+ resets = <&CRG 0xe4 0>;
+};
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index e434854..b6baebf 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -1,3 +1,10 @@
+config COMMON_CLK_HI3519
+ tristate "Clock Driver for Hi3519"
+ depends on ARCH_HISI
+ default y
+ help
+ Build the clock driver for hi3519.
+
config COMMON_CLK_HI6220
bool "Hi6220 Clock Driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 74dba31..3f57b09 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -4,8 +4,10 @@
obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o
+obj-$(CONFIG_RESET_CONTROLLER) += reset.o
obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o
obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o
obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
obj-$(CONFIG_COMMON_CLK_HI6220) += clk-hi6220.o
obj-$(CONFIG_STUB_CLK_HI6220) += clk-hi6220-stub.o
+obj-$(CONFIG_COMMON_CLK_HI3519) += clk-hi3519.o
diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
new file mode 100644
index 0000000..72d3a7b0
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3519.c
@@ -0,0 +1,105 @@
+/*
+ * Hi3519 Clock Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <dt-bindings/clock/hi3519-clock.h>
+#include <linux/delay.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include "clk.h"
+#include "reset.h"
+
+#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
+#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
+#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
+#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
+#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
+#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
+#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
+#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
+#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
+#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
+
+#define HI3519_NR_CLKS 128
+
+static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
+ { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
+ { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
+ { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
+ { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
+ { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
+ { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
+ { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
+ { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
+ { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
+ { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
+};
+
+static const char *fmc_mux_p[] __initconst = {
+ "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
+static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
+static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
+ { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
+ CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
+};
+
+static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
+ /* fmc */
+ { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
+ CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
+ /* uart */
+ { HI3519_UART0_CLK, "clk_uart0", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
+ { HI3519_UART1_CLK, "clk_uart1", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
+ { HI3519_UART2_CLK, "clk_uart2", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
+ { HI3519_UART3_CLK, "clk_uart3", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
+ { HI3519_UART4_CLK, "clk_uart4", "24m",
+ CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
+ { HI3519_SPI0_CLK, "clk_spi0", "50m",
+ CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
+ { HI3519_SPI1_CLK, "clk_spi1", "50m",
+ CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
+ { HI3519_SPI2_CLK, "clk_spi2", "50m",
+ CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
+};
+
+static void __init hi3519_clk_init(struct device_node *np)
+{
+ struct hisi_clock_data *clk_data;
+
+
+ clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
+ if (!clk_data)
+ return;
+
+ hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
+ ARRAY_SIZE(hi3519_fixed_rate_clks),
+ clk_data);
+ hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
+ clk_data);
+ hisi_clk_register_gate(hi3519_gate_clks,
+ ARRAY_SIZE(hi3519_gate_clks), clk_data);
+
+ hisi_reset_init(np);
+}
+
+CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
new file mode 100644
index 0000000..f11561c
--- /dev/null
+++ b/drivers/clk/hisilicon/reset.c
@@ -0,0 +1,129 @@
+/*
+ * Hisilicon Reset Controller Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+#define HISI_RESET_BIT_MASK 0x1f
+#define HISI_RESET_OFFSET_SHIFT 8
+#define HISI_RESET_OFFSET_MASK 0xffff00
+
+struct hisi_reset_controller {
+ spinlock_t lock;
+ void __iomem *membase;
+ struct reset_controller_dev rcdev;
+};
+
+
+#define to_hisi_reset_controller(rcdev) \
+ container_of(rcdev, struct hisi_reset_controller, rcdev)
+
+static int hisi_reset_of_xlate(struct reset_controller_dev *rcdev,
+ const struct of_phandle_args *reset_spec)
+{
+ u32 offset;
+ u8 bit;
+
+ if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
+ return -EINVAL;
+
+ offset = (reset_spec->args[0] << HISI_RESET_OFFSET_SHIFT)
+ & HISI_RESET_OFFSET_MASK;
+ bit = reset_spec->args[1] & HISI_RESET_BIT_MASK;
+ return (offset | bit);
+}
+
+static int hisi_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
+ unsigned long flags;
+ u32 offset, reg;
+ u8 bit;
+
+ offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
+ bit = id & HISI_RESET_BIT_MASK;
+
+ spin_lock_irqsave(&rstc->lock, flags);
+
+ reg = readl(rstc->membase + offset);
+ writel(reg | BIT(bit), rstc->membase + offset);
+
+ spin_unlock_irqrestore(&rstc->lock, flags);
+
+ return 0;
+}
+
+static int hisi_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
+ unsigned long flags;
+ u32 offset, reg;
+ u8 bit;
+
+ offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
+ bit = id & HISI_RESET_BIT_MASK;
+
+ spin_lock_irqsave(&rstc->lock, flags);
+
+ reg = readl(rstc->membase + offset);
+ writel(reg & ~BIT(bit), rstc->membase + offset);
+
+ spin_unlock_irqrestore(&rstc->lock, flags);
+
+ return 0;
+}
+
+static struct reset_control_ops hisi_reset_ops = {
+ .assert = hisi_reset_assert,
+ .deassert = hisi_reset_deassert,
+};
+
+int __init hisi_reset_init(struct device_node *np)
+{
+ struct hisi_reset_controller *rstc;
+
+ rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
+ if (!rstc)
+ return -ENOMEM;
+
+ rstc->membase = of_iomap(np, 0);
+ if (!rstc->membase)
+ return -EINVAL;
+
+ spin_lock_init(&rstc->lock);
+
+ rstc->rcdev.owner = THIS_MODULE;
+ rstc->rcdev.ops = &hisi_reset_ops;
+ rstc->rcdev.of_node = np;
+ rstc->rcdev.of_reset_n_cells = 2;
+ rstc->rcdev.of_xlate = hisi_reset_of_xlate;
+
+ return reset_controller_register(&rstc->rcdev);
+}
diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
new file mode 100644
index 0000000..37856089
--- /dev/null
+++ b/drivers/clk/hisilicon/reset.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __HISI_RESET_H
+#define __HISI_RESET_H
+
+#include <linux/of.h>
+
+#ifdef CONFIG_RESET_CONTROLLER
+int __init hisi_reset_init(struct device_node *np);
+#else
+static inline int __init hisi_reset_init(struct device_node *np)
+{
+ return 0;
+}
+#endif
+
+#endif /* __HISI_RESET_H */
diff --git a/include/dt-bindings/clock/hi3519-clock.h b/include/dt-bindings/clock/hi3519-clock.h
new file mode 100644
index 0000000..1e4a3c1
--- /dev/null
+++ b/include/dt-bindings/clock/hi3519-clock.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __DTS_HI3519_CLOCK_H
+#define __DTS_HI3519_CLOCK_H
+
+#define HI3519_FIXED_3M 1
+#define HI3519_FMC_CLK 2
+#define HI3519_USB2_BUS_CLK 3
+#define HI3519_USB2_PORT_CLK 4
+#define HI3519_USB3_CLK 5
+#define HI3519_ETH_PHY_CLK 6
+#define HI3519_ETH_MAC_CLK 7
+#define HI3519_ETH_MACIF_CLK 8
+#define HI3519_PWM_CLK 9
+#define HI3519_DMA_CLK 10
+#define HI3519_SPI0_CLK 11
+#define HI3519_SPI1_CLK 12
+#define HI3519_SPI2_CLK 13
+#define HI3519_IR_CLK 14
+#define HI3519_UART0_CLK 15
+#define HI3519_UART1_CLK 16
+#define HI3519_UART2_CLK 17
+#define HI3519_UART3_CLK 18
+#define HI3519_UART4_CLK 19
+
+#define HI3519_EXT_CLKS 19
+
+#endif /* __DTS_HI3519_CLOCK_H */
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 2/6] ARM: hisi: add compatible string for Hi3519 soc
2016-01-08 2:16 ` Jiancheng Xue
(?)
@ 2016-01-08 2:16 ` Jiancheng Xue
-1 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
add compatible string for Hi3519 soc.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
arch/arm/mach-hisi/hisilicon.c | 23 ++++-------------------
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..00dae89 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -54,30 +54,15 @@ DT_MACHINE_START(HI3620, "Hisilicon Hi3620 (Flattened Device Tree)")
.dt_compat = hi3xxx_compat,
MACHINE_END
-static const char *const hix5hd2_compat[] __initconst = {
+static const char *const hisilicon_compat[] __initconst = {
"hisilicon,hix5hd2",
- NULL,
-};
-
-DT_MACHINE_START(HIX5HD2_DT, "Hisilicon HIX5HD2 (Flattened Device Tree)")
- .dt_compat = hix5hd2_compat,
-MACHINE_END
-
-static const char *const hip04_compat[] __initconst = {
"hisilicon,hip04-d01",
- NULL,
-};
-
-DT_MACHINE_START(HIP04, "Hisilicon HiP04 (Flattened Device Tree)")
- .dt_compat = hip04_compat,
-MACHINE_END
-
-static const char *const hip01_compat[] __initconst = {
"hisilicon,hip01",
"hisilicon,hip01-ca9x2",
+ "hisilicon,hi3519",
NULL,
};
-DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
- .dt_compat = hip01_compat,
+DT_MACHINE_START(HISILICON_DT, "HiSilicon Soc")
+ .dt_compat = hisilicon_compat,
MACHINE_END
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 2/6] ARM: hisi: add compatible string for Hi3519 soc
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
add compatible string for Hi3519 soc.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
arch/arm/mach-hisi/hisilicon.c | 23 ++++-------------------
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..00dae89 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -54,30 +54,15 @@ DT_MACHINE_START(HI3620, "Hisilicon Hi3620 (Flattened Device Tree)")
.dt_compat = hi3xxx_compat,
MACHINE_END
-static const char *const hix5hd2_compat[] __initconst = {
+static const char *const hisilicon_compat[] __initconst = {
"hisilicon,hix5hd2",
- NULL,
-};
-
-DT_MACHINE_START(HIX5HD2_DT, "Hisilicon HIX5HD2 (Flattened Device Tree)")
- .dt_compat = hix5hd2_compat,
-MACHINE_END
-
-static const char *const hip04_compat[] __initconst = {
"hisilicon,hip04-d01",
- NULL,
-};
-
-DT_MACHINE_START(HIP04, "Hisilicon HiP04 (Flattened Device Tree)")
- .dt_compat = hip04_compat,
-MACHINE_END
-
-static const char *const hip01_compat[] __initconst = {
"hisilicon,hip01",
"hisilicon,hip01-ca9x2",
+ "hisilicon,hi3519",
NULL,
};
-DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
- .dt_compat = hip01_compat,
+DT_MACHINE_START(HISILICON_DT, "HiSilicon Soc")
+ .dt_compat = hisilicon_compat,
MACHINE_END
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 2/6] ARM: hisi: add compatible string for Hi3519 soc
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: linux-arm-kernel
add compatible string for Hi3519 soc.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
arch/arm/mach-hisi/hisilicon.c | 23 ++++-------------------
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..00dae89 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -54,30 +54,15 @@ DT_MACHINE_START(HI3620, "Hisilicon Hi3620 (Flattened Device Tree)")
.dt_compat = hi3xxx_compat,
MACHINE_END
-static const char *const hix5hd2_compat[] __initconst = {
+static const char *const hisilicon_compat[] __initconst = {
"hisilicon,hix5hd2",
- NULL,
-};
-
-DT_MACHINE_START(HIX5HD2_DT, "Hisilicon HIX5HD2 (Flattened Device Tree)")
- .dt_compat = hix5hd2_compat,
-MACHINE_END
-
-static const char *const hip04_compat[] __initconst = {
"hisilicon,hip04-d01",
- NULL,
-};
-
-DT_MACHINE_START(HIP04, "Hisilicon HiP04 (Flattened Device Tree)")
- .dt_compat = hip04_compat,
-MACHINE_END
-
-static const char *const hip01_compat[] __initconst = {
"hisilicon,hip01",
"hisilicon,hip01-ca9x2",
+ "hisilicon,hi3519",
NULL,
};
-DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
- .dt_compat = hip01_compat,
+DT_MACHINE_START(HISILICON_DT, "HiSilicon Soc")
+ .dt_compat = hisilicon_compat,
MACHINE_END
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 3/6] ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
enable CONFIG_RESET_CONTROLLER in hisi_defconfig
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
arch/arm/configs/hisi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index b2e340b..ba62c07 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -75,6 +75,7 @@ CONFIG_DMADEVICES=y
CONFIG_DW_DMAC=y
CONFIG_PL330_DMA=y
CONFIG_PWM=y
+CONFIG_RESET_CONTROLLER=y
CONFIG_PHY_HIX5HD2_SATA=y
CONFIG_EXT4_FS=y
CONFIG_TMPFS=y
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 3/6] ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, linux-lFZ/pmaqli7XmaaqVzeoHQ,
khilman-QSEj5FYQhm4dnm+yROfE0A, arnd-r2nGTMty4D4,
olof-nZhT3qVonbNeoWH0uzbU5w, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A,
zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A,
bintian.wang-hv44wF8Li93QT0dZR+AlfA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
yanhaifeng-C8/M+/jPZTeaMJb+Lgu22Q,
yanghongwei-C8/M+/jPZTeaMJb+Lgu22Q,
suwenping-C8/M+/jPZTeaMJb+Lgu22Q, ml.yang-C8/M+/jPZTeaMJb+Lgu22Q,
gaofei-C8/M+/jPZTeaMJb+Lgu22Q,
zhangzhenxing-C8/M+/jPZTeaMJb+Lgu22Q,
xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q, Jiancheng Xue
enable CONFIG_RESET_CONTROLLER in hisi_defconfig
Signed-off-by: Jiancheng Xue <xuejiancheng-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
arch/arm/configs/hisi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index b2e340b..ba62c07 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -75,6 +75,7 @@ CONFIG_DMADEVICES=y
CONFIG_DW_DMAC=y
CONFIG_PL330_DMA=y
CONFIG_PWM=y
+CONFIG_RESET_CONTROLLER=y
CONFIG_PHY_HIX5HD2_SATA=y
CONFIG_EXT4_FS=y
CONFIG_TMPFS=y
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 3/6] ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: linux-arm-kernel
enable CONFIG_RESET_CONTROLLER in hisi_defconfig
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
arch/arm/configs/hisi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index b2e340b..ba62c07 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -75,6 +75,7 @@ CONFIG_DMADEVICES=y
CONFIG_DW_DMAC=y
CONFIG_PL330_DMA=y
CONFIG_PWM=y
+CONFIG_RESET_CONTROLLER=y
CONFIG_PHY_HIX5HD2_SATA=y
CONFIG_EXT4_FS=y
CONFIG_TMPFS=y
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 4/6] ARM: debug: add hi3519 debug uart
2016-01-08 2:16 ` Jiancheng Xue
(?)
@ 2016-01-08 2:16 ` Jiancheng Xue
-1 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
add hi3519 debug uart.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
arch/arm/Kconfig.debug | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 259c0ca..29af057 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -270,6 +270,14 @@ choice
Say Y here if you want the debug print routines to direct
their output to the 8250 at PCI COM1.
+ config DEBUG_HI3519_UART
+ bool "Hisilicon Hi3519 Debug UART"
+ depends on ARCH_HISI
+ select DEBUG_UART_PL01X
+ help
+ Say Y here if you want kernel low-level debugging support
+ on HI3519 UART.
+
config DEBUG_HI3620_UART
bool "Hisilicon HI3620 Debug UART"
depends on ARCH_HI3xxx
@@ -1449,6 +1457,7 @@ config DEBUG_UART_PHYS
default 0xf7fc9000 if DEBUG_BERLIN_UART
default 0xf8b00000 if DEBUG_HIX5HD2_UART
default 0xf991e000 if DEBUG_QCOM_UARTDM
+ default 0x12100000 if DEBUG_HI3519_UART
default 0xfcb00000 if DEBUG_HI3620_UART
default 0xfd883000 if DEBUG_ALPINE_UART0
default 0xfe800000 if ARCH_IOP32X
@@ -1529,6 +1538,7 @@ config DEBUG_UART_VIRT
default 0xfe230000 if DEBUG_PICOXCELL_UART
default 0xfe300000 if DEBUG_BCM_KONA_UART
default 0xfe800000 if ARCH_IOP32X
+ default 0xfef00000 if DEBUG_HI3519_UART
default 0xfeb00000 if DEBUG_HI3620_UART || DEBUG_HIX5HD2_UART
default 0xfeb24000 if DEBUG_RK3X_UART0
default 0xfeb26000 if DEBUG_RK3X_UART1
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 4/6] ARM: debug: add hi3519 debug uart
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
add hi3519 debug uart.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
arch/arm/Kconfig.debug | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 259c0ca..29af057 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -270,6 +270,14 @@ choice
Say Y here if you want the debug print routines to direct
their output to the 8250 at PCI COM1.
+ config DEBUG_HI3519_UART
+ bool "Hisilicon Hi3519 Debug UART"
+ depends on ARCH_HISI
+ select DEBUG_UART_PL01X
+ help
+ Say Y here if you want kernel low-level debugging support
+ on HI3519 UART.
+
config DEBUG_HI3620_UART
bool "Hisilicon HI3620 Debug UART"
depends on ARCH_HI3xxx
@@ -1449,6 +1457,7 @@ config DEBUG_UART_PHYS
default 0xf7fc9000 if DEBUG_BERLIN_UART
default 0xf8b00000 if DEBUG_HIX5HD2_UART
default 0xf991e000 if DEBUG_QCOM_UARTDM
+ default 0x12100000 if DEBUG_HI3519_UART
default 0xfcb00000 if DEBUG_HI3620_UART
default 0xfd883000 if DEBUG_ALPINE_UART0
default 0xfe800000 if ARCH_IOP32X
@@ -1529,6 +1538,7 @@ config DEBUG_UART_VIRT
default 0xfe230000 if DEBUG_PICOXCELL_UART
default 0xfe300000 if DEBUG_BCM_KONA_UART
default 0xfe800000 if ARCH_IOP32X
+ default 0xfef00000 if DEBUG_HI3519_UART
default 0xfeb00000 if DEBUG_HI3620_UART || DEBUG_HIX5HD2_UART
default 0xfeb24000 if DEBUG_RK3X_UART0
default 0xfeb26000 if DEBUG_RK3X_UART1
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 4/6] ARM: debug: add hi3519 debug uart
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: linux-arm-kernel
add hi3519 debug uart.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
arch/arm/Kconfig.debug | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 259c0ca..29af057 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -270,6 +270,14 @@ choice
Say Y here if you want the debug print routines to direct
their output to the 8250 at PCI COM1.
+ config DEBUG_HI3519_UART
+ bool "Hisilicon Hi3519 Debug UART"
+ depends on ARCH_HISI
+ select DEBUG_UART_PL01X
+ help
+ Say Y here if you want kernel low-level debugging support
+ on HI3519 UART.
+
config DEBUG_HI3620_UART
bool "Hisilicon HI3620 Debug UART"
depends on ARCH_HI3xxx
@@ -1449,6 +1457,7 @@ config DEBUG_UART_PHYS
default 0xf7fc9000 if DEBUG_BERLIN_UART
default 0xf8b00000 if DEBUG_HIX5HD2_UART
default 0xf991e000 if DEBUG_QCOM_UARTDM
+ default 0x12100000 if DEBUG_HI3519_UART
default 0xfcb00000 if DEBUG_HI3620_UART
default 0xfd883000 if DEBUG_ALPINE_UART0
default 0xfe800000 if ARCH_IOP32X
@@ -1529,6 +1538,7 @@ config DEBUG_UART_VIRT
default 0xfe230000 if DEBUG_PICOXCELL_UART
default 0xfe300000 if DEBUG_BCM_KONA_UART
default 0xfe800000 if ARCH_IOP32X
+ default 0xfef00000 if DEBUG_HI3519_UART
default 0xfeb00000 if DEBUG_HI3620_UART || DEBUG_HIX5HD2_UART
default 0xfeb24000 if DEBUG_RK3X_UART0
default 0xfeb26000 if DEBUG_RK3X_UART1
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-08 2:16 ` Jiancheng Xue
(?)
@ 2016-01-08 2:16 ` Jiancheng Xue
-1 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
Add device tree bindings for Hi3519 system controller.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
new file mode 100644
index 0000000..115c5be
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
@@ -0,0 +1,14 @@
+* Hisilicon Hi3519 System Controller Block
+
+This bindings use the following binding:
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Required properties:
+- compatible: "hisilicon,hi3519-sysctrl".
+- reg: the register region of this block
+
+Examples:
+sysctrl: system-controller@12010000 {
+ compatible = "hisilicon,hi3519-sysctrl", "syscon";
+ reg = <0x12010000 0x1000>;
+};
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
Add device tree bindings for Hi3519 system controller.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
new file mode 100644
index 0000000..115c5be
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
@@ -0,0 +1,14 @@
+* Hisilicon Hi3519 System Controller Block
+
+This bindings use the following binding:
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Required properties:
+- compatible: "hisilicon,hi3519-sysctrl".
+- reg: the register region of this block
+
+Examples:
+sysctrl: system-controller@12010000 {
+ compatible = "hisilicon,hi3519-sysctrl", "syscon";
+ reg = <0x12010000 0x1000>;
+};
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: linux-arm-kernel
Add device tree bindings for Hi3519 system controller.
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
new file mode 100644
index 0000000..115c5be
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
@@ -0,0 +1,14 @@
+* Hisilicon Hi3519 System Controller Block
+
+This bindings use the following binding:
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Required properties:
+- compatible: "hisilicon,hi3519-sysctrl".
+- reg: the register region of this block
+
+Examples:
+sysctrl: system-controller at 12010000 {
+ compatible = "hisilicon,hi3519-sysctrl", "syscon";
+ reg = <0x12010000 0x1000>;
+};
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 6/6] ARM: dts: add dts files for Hi3519
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang
Cc: linux-kernel, linux-clk, devicetree, linux-arm-kernel,
yanhaifeng, yanghongwei, suwenping, ml.yang, gaofei,
zhangzhenxing, xuejiancheng, Jiancheng Xue
add dts files for Hi3519
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/hi3519-demb.dts | 42 +++++++++
arch/arm/boot/dts/hi3519.dtsi | 175 ++++++++++++++++++++++++++++++++++++++
3 files changed, 219 insertions(+)
create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
create mode 100644 arch/arm/boot/dts/hi3519.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..1ff3ed9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -135,6 +135,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5800-peach-pi.dtb
dtb-$(CONFIG_ARCH_HI3xxx) += \
hi3620-hi4511.dtb
+dtb-$(CONFIG_ARCH_HISI) += \
+ hi3519-demb.dtb
dtb-$(CONFIG_ARCH_HIX5HD2) += \
hisi-x5hd2-dkb.dtb
dtb-$(CONFIG_ARCH_HIGHBANK) += \
diff --git a/arch/arm/boot/dts/hi3519-demb.dts b/arch/arm/boot/dts/hi3519-demb.dts
new file mode 100644
index 0000000..6991ab6
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+/dts-v1/;
+#include "hi3519.dtsi"
+
+/ {
+ model = "HiSilicon HI3519 DEMO Board";
+ compatible = "hisilicon,hi3519";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dual_timer0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
new file mode 100644
index 0000000..95137c7
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <dt-bindings/clock/hi3519-clock.h>
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chosen { };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0>;
+ };
+ };
+
+ gic: interrupt-controller@10300000 {
+ compatible = "arm,cortex-a7-gic";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+ ranges;
+
+
+ uart0: serial@12100000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12100000 0x1000>;
+ interrupts = <0 4 4>;
+ clocks = <&crg HI3519_UART0_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart1: serial@12101000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12101000 0x1000>;
+ interrupts = <0 5 4>;
+ clocks = <&crg HI3519_UART1_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart2: serial@12102000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12102000 0x1000>;
+ interrupts = <0 6 4>;
+ clocks = <&crg HI3519_UART2_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart3: serial@12103000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12103000 0x1000>;
+ interrupts = <0 7 4>;
+ clocks = <&crg HI3519_UART3_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart4: serial@12104000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12104000 0x1000>;
+ interrupts = <0 8 4>;
+ clocks = <&crg HI3519_UART4_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ dual_timer0: timer@12000000 {
+ compatible = "arm,sp804", "arm,primecell";
+ interrupts = <0 64 4>, <0 65 4>;
+ reg = <0x12000000 0x1000>;
+ clocks = <&crg HI3519_FIXED_3M>;
+ status = "disable";
+ };
+
+ dual_timer1: timer@12001000 {
+ compatible = "arm,sp804", "arm,primecell";
+ interrupts = <0 66 4>, <0 67 4>;
+ reg = <0x12001000 0x1000>;
+ clocks = <&crg HI3519_FIXED_3M>;
+ status = "disable";
+ };
+
+ dual_timer2: timer@12002000 {
+ compatible = "arm,sp804", "arm,primecell";
+ interrupts = <0 68 4>, <0 69 4>;
+ reg = <0x12002000 0x1000>;
+ clocks = <&crg HI3519_FIXED_3M>;
+ status = "disable";
+ };
+
+ spi_bus0: spi@12120000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0x12120000 0x1000>;
+ interrupts = <0 9 4>;
+ clocks = <&crg HI3519_SPI0_CLK>;
+ clock-names = "apb_pclk";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disable";
+ };
+
+ spi_bus1: spi@12121000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0x12121000 0x1000>;
+ interrupts = <0 10 4>;
+ clocks = <&crg HI3519_SPI1_CLK>;
+ clock-names = "apb_pclk";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disable";
+ };
+
+ spi_bus2: spi@12122000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0x12122000 0x1000>;
+ interrupts = <0 11 4>;
+ clocks = <&crg HI3519_SPI2_CLK>;
+ clock-names = "apb_pclk";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disable";
+ };
+
+ sysctrl: system-controller@12020000 {
+ compatible = "hisilicon,hi3519-sysctrl", "syscon";
+ reg = <0x12020000 0x1000>;
+ };
+
+ reboot {
+ compatible = "syscon-reboot";
+ regmap = <&sysctrl>;
+ offset = <0x4>;
+ mask = <0xdeadbeef>;
+ };
+
+ crg: clock-reset-controller@12010000 {
+ compatible = "hisilicon,hi3519-crg";
+ #clock-cells = <1>;
+ #reset-cells = <2>;
+ reg = <0x12010000 0x10000>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 6/6] ARM: dts: add dts files for Hi3519
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, linux-lFZ/pmaqli7XmaaqVzeoHQ,
khilman-QSEj5FYQhm4dnm+yROfE0A, arnd-r2nGTMty4D4,
olof-nZhT3qVonbNeoWH0uzbU5w, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A,
zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A,
bintian.wang-hv44wF8Li93QT0dZR+AlfA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
yanhaifeng-C8/M+/jPZTeaMJb+Lgu22Q,
yanghongwei-C8/M+/jPZTeaMJb+Lgu22Q,
suwenping-C8/M+/jPZTeaMJb+Lgu22Q, ml.yang-C8/M+/jPZTeaMJb+Lgu22Q,
gaofei-C8/M+/jPZTeaMJb+Lgu22Q,
zhangzhenxing-C8/M+/jPZTeaMJb+Lgu22Q,
xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q, Jiancheng Xue
add dts files for Hi3519
Signed-off-by: Jiancheng Xue <xuejiancheng-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/hi3519-demb.dts | 42 +++++++++
arch/arm/boot/dts/hi3519.dtsi | 175 ++++++++++++++++++++++++++++++++++++++
3 files changed, 219 insertions(+)
create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
create mode 100644 arch/arm/boot/dts/hi3519.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..1ff3ed9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -135,6 +135,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5800-peach-pi.dtb
dtb-$(CONFIG_ARCH_HI3xxx) += \
hi3620-hi4511.dtb
+dtb-$(CONFIG_ARCH_HISI) += \
+ hi3519-demb.dtb
dtb-$(CONFIG_ARCH_HIX5HD2) += \
hisi-x5hd2-dkb.dtb
dtb-$(CONFIG_ARCH_HIGHBANK) += \
diff --git a/arch/arm/boot/dts/hi3519-demb.dts b/arch/arm/boot/dts/hi3519-demb.dts
new file mode 100644
index 0000000..6991ab6
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+/dts-v1/;
+#include "hi3519.dtsi"
+
+/ {
+ model = "HiSilicon HI3519 DEMO Board";
+ compatible = "hisilicon,hi3519";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dual_timer0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
new file mode 100644
index 0000000..95137c7
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <dt-bindings/clock/hi3519-clock.h>
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chosen { };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0>;
+ };
+ };
+
+ gic: interrupt-controller@10300000 {
+ compatible = "arm,cortex-a7-gic";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+ ranges;
+
+
+ uart0: serial@12100000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12100000 0x1000>;
+ interrupts = <0 4 4>;
+ clocks = <&crg HI3519_UART0_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart1: serial@12101000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12101000 0x1000>;
+ interrupts = <0 5 4>;
+ clocks = <&crg HI3519_UART1_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart2: serial@12102000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12102000 0x1000>;
+ interrupts = <0 6 4>;
+ clocks = <&crg HI3519_UART2_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart3: serial@12103000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12103000 0x1000>;
+ interrupts = <0 7 4>;
+ clocks = <&crg HI3519_UART3_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart4: serial@12104000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12104000 0x1000>;
+ interrupts = <0 8 4>;
+ clocks = <&crg HI3519_UART4_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ dual_timer0: timer@12000000 {
+ compatible = "arm,sp804", "arm,primecell";
+ interrupts = <0 64 4>, <0 65 4>;
+ reg = <0x12000000 0x1000>;
+ clocks = <&crg HI3519_FIXED_3M>;
+ status = "disable";
+ };
+
+ dual_timer1: timer@12001000 {
+ compatible = "arm,sp804", "arm,primecell";
+ interrupts = <0 66 4>, <0 67 4>;
+ reg = <0x12001000 0x1000>;
+ clocks = <&crg HI3519_FIXED_3M>;
+ status = "disable";
+ };
+
+ dual_timer2: timer@12002000 {
+ compatible = "arm,sp804", "arm,primecell";
+ interrupts = <0 68 4>, <0 69 4>;
+ reg = <0x12002000 0x1000>;
+ clocks = <&crg HI3519_FIXED_3M>;
+ status = "disable";
+ };
+
+ spi_bus0: spi@12120000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0x12120000 0x1000>;
+ interrupts = <0 9 4>;
+ clocks = <&crg HI3519_SPI0_CLK>;
+ clock-names = "apb_pclk";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disable";
+ };
+
+ spi_bus1: spi@12121000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0x12121000 0x1000>;
+ interrupts = <0 10 4>;
+ clocks = <&crg HI3519_SPI1_CLK>;
+ clock-names = "apb_pclk";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disable";
+ };
+
+ spi_bus2: spi@12122000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0x12122000 0x1000>;
+ interrupts = <0 11 4>;
+ clocks = <&crg HI3519_SPI2_CLK>;
+ clock-names = "apb_pclk";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disable";
+ };
+
+ sysctrl: system-controller@12020000 {
+ compatible = "hisilicon,hi3519-sysctrl", "syscon";
+ reg = <0x12020000 0x1000>;
+ };
+
+ reboot {
+ compatible = "syscon-reboot";
+ regmap = <&sysctrl>;
+ offset = <0x4>;
+ mask = <0xdeadbeef>;
+ };
+
+ crg: clock-reset-controller@12010000 {
+ compatible = "hisilicon,hi3519-crg";
+ #clock-cells = <1>;
+ #reset-cells = <2>;
+ reg = <0x12010000 0x10000>;
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 103+ messages in thread
* [PATCH v5 6/6] ARM: dts: add dts files for Hi3519
@ 2016-01-08 2:16 ` Jiancheng Xue
0 siblings, 0 replies; 103+ messages in thread
From: Jiancheng Xue @ 2016-01-08 2:16 UTC (permalink / raw)
To: linux-arm-kernel
add dts files for Hi3519
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/hi3519-demb.dts | 42 +++++++++
arch/arm/boot/dts/hi3519.dtsi | 175 ++++++++++++++++++++++++++++++++++++++
3 files changed, 219 insertions(+)
create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
create mode 100644 arch/arm/boot/dts/hi3519.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..1ff3ed9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -135,6 +135,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5800-peach-pi.dtb
dtb-$(CONFIG_ARCH_HI3xxx) += \
hi3620-hi4511.dtb
+dtb-$(CONFIG_ARCH_HISI) += \
+ hi3519-demb.dtb
dtb-$(CONFIG_ARCH_HIX5HD2) += \
hisi-x5hd2-dkb.dtb
dtb-$(CONFIG_ARCH_HIGHBANK) += \
diff --git a/arch/arm/boot/dts/hi3519-demb.dts b/arch/arm/boot/dts/hi3519-demb.dts
new file mode 100644
index 0000000..6991ab6
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+/dts-v1/;
+#include "hi3519.dtsi"
+
+/ {
+ model = "HiSilicon HI3519 DEMO Board";
+ compatible = "hisilicon,hi3519";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dual_timer0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
new file mode 100644
index 0000000..95137c7
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include <dt-bindings/clock/hi3519-clock.h>
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chosen { };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0>;
+ };
+ };
+
+ gic: interrupt-controller at 10300000 {
+ compatible = "arm,cortex-a7-gic";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+ ranges;
+
+
+ uart0: serial at 12100000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12100000 0x1000>;
+ interrupts = <0 4 4>;
+ clocks = <&crg HI3519_UART0_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart1: serial at 12101000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12101000 0x1000>;
+ interrupts = <0 5 4>;
+ clocks = <&crg HI3519_UART1_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart2: serial at 12102000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12102000 0x1000>;
+ interrupts = <0 6 4>;
+ clocks = <&crg HI3519_UART2_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart3: serial at 12103000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12103000 0x1000>;
+ interrupts = <0 7 4>;
+ clocks = <&crg HI3519_UART3_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ uart4: serial at 12104000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x12104000 0x1000>;
+ interrupts = <0 8 4>;
+ clocks = <&crg HI3519_UART4_CLK>;
+ clock-names = "apb_pclk";
+ status = "disable";
+ };
+
+ dual_timer0: timer at 12000000 {
+ compatible = "arm,sp804", "arm,primecell";
+ interrupts = <0 64 4>, <0 65 4>;
+ reg = <0x12000000 0x1000>;
+ clocks = <&crg HI3519_FIXED_3M>;
+ status = "disable";
+ };
+
+ dual_timer1: timer at 12001000 {
+ compatible = "arm,sp804", "arm,primecell";
+ interrupts = <0 66 4>, <0 67 4>;
+ reg = <0x12001000 0x1000>;
+ clocks = <&crg HI3519_FIXED_3M>;
+ status = "disable";
+ };
+
+ dual_timer2: timer at 12002000 {
+ compatible = "arm,sp804", "arm,primecell";
+ interrupts = <0 68 4>, <0 69 4>;
+ reg = <0x12002000 0x1000>;
+ clocks = <&crg HI3519_FIXED_3M>;
+ status = "disable";
+ };
+
+ spi_bus0: spi at 12120000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0x12120000 0x1000>;
+ interrupts = <0 9 4>;
+ clocks = <&crg HI3519_SPI0_CLK>;
+ clock-names = "apb_pclk";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disable";
+ };
+
+ spi_bus1: spi at 12121000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0x12121000 0x1000>;
+ interrupts = <0 10 4>;
+ clocks = <&crg HI3519_SPI1_CLK>;
+ clock-names = "apb_pclk";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disable";
+ };
+
+ spi_bus2: spi at 12122000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0x12122000 0x1000>;
+ interrupts = <0 11 4>;
+ clocks = <&crg HI3519_SPI2_CLK>;
+ clock-names = "apb_pclk";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disable";
+ };
+
+ sysctrl: system-controller at 12020000 {
+ compatible = "hisilicon,hi3519-sysctrl", "syscon";
+ reg = <0x12020000 0x1000>;
+ };
+
+ reboot {
+ compatible = "syscon-reboot";
+ regmap = <&sysctrl>;
+ offset = <0x4>;
+ mask = <0xdeadbeef>;
+ };
+
+ crg: clock-reset-controller at 12010000 {
+ compatible = "hisilicon,hi3519-crg";
+ #clock-cells = <1>;
+ #reset-cells = <2>;
+ reg = <0x12010000 0x10000>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related [flat|nested] 103+ messages in thread
* Re: [PATCH v5 4/6] ARM: debug: add hi3519 debug uart
2016-01-08 2:16 ` Jiancheng Xue
@ 2016-01-08 15:08 ` Russell King - ARM Linux
-1 siblings, 0 replies; 103+ messages in thread
From: Russell King - ARM Linux @ 2016-01-08 15:08 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Fri, Jan 08, 2016 at 10:16:38AM +0800, Jiancheng Xue wrote:
> @@ -1449,6 +1457,7 @@ config DEBUG_UART_PHYS
> default 0xf7fc9000 if DEBUG_BERLIN_UART
> default 0xf8b00000 if DEBUG_HIX5HD2_UART
> default 0xf991e000 if DEBUG_QCOM_UARTDM
> + default 0x12100000 if DEBUG_HI3519_UART
> default 0xfcb00000 if DEBUG_HI3620_UART
> default 0xfd883000 if DEBUG_ALPINE_UART0
> default 0xfe800000 if ARCH_IOP32X
Please insert at the appropriate location - examination of the list
of defaults will show that it's sorted numerically, please keep this
sorted numerically.
> @@ -1529,6 +1538,7 @@ config DEBUG_UART_VIRT
> default 0xfe230000 if DEBUG_PICOXCELL_UART
> default 0xfe300000 if DEBUG_BCM_KONA_UART
> default 0xfe800000 if ARCH_IOP32X
> + default 0xfef00000 if DEBUG_HI3519_UART
> default 0xfeb00000 if DEBUG_HI3620_UART || DEBUG_HIX5HD2_UART
> default 0xfeb24000 if DEBUG_RK3X_UART0
> default 0xfeb26000 if DEBUG_RK3X_UART1
Same for here.
Thanks.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 4/6] ARM: debug: add hi3519 debug uart
@ 2016-01-08 15:08 ` Russell King - ARM Linux
0 siblings, 0 replies; 103+ messages in thread
From: Russell King - ARM Linux @ 2016-01-08 15:08 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 08, 2016 at 10:16:38AM +0800, Jiancheng Xue wrote:
> @@ -1449,6 +1457,7 @@ config DEBUG_UART_PHYS
> default 0xf7fc9000 if DEBUG_BERLIN_UART
> default 0xf8b00000 if DEBUG_HIX5HD2_UART
> default 0xf991e000 if DEBUG_QCOM_UARTDM
> + default 0x12100000 if DEBUG_HI3519_UART
> default 0xfcb00000 if DEBUG_HI3620_UART
> default 0xfd883000 if DEBUG_ALPINE_UART0
> default 0xfe800000 if ARCH_IOP32X
Please insert at the appropriate location - examination of the list
of defaults will show that it's sorted numerically, please keep this
sorted numerically.
> @@ -1529,6 +1538,7 @@ config DEBUG_UART_VIRT
> default 0xfe230000 if DEBUG_PICOXCELL_UART
> default 0xfe300000 if DEBUG_BCM_KONA_UART
> default 0xfe800000 if ARCH_IOP32X
> + default 0xfef00000 if DEBUG_HI3519_UART
> default 0xfeb00000 if DEBUG_HI3620_UART || DEBUG_HIX5HD2_UART
> default 0xfeb24000 if DEBUG_RK3X_UART0
> default 0xfeb26000 if DEBUG_RK3X_UART1
Same for here.
Thanks.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 6/6] ARM: dts: add dts files for Hi3519
@ 2016-01-08 15:10 ` Russell King - ARM Linux
0 siblings, 0 replies; 103+ messages in thread
From: Russell King - ARM Linux @ 2016-01-08 15:10 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Fri, Jan 08, 2016 at 10:16:40AM +0800, Jiancheng Xue wrote:
> + uart0: serial@12100000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x12100000 0x1000>;
> + interrupts = <0 4 4>;
Should the last digit there be IRQ_TYPE_LEVEL_HIGH (and same for the
other interrupts= after this?)
Thanks.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 6/6] ARM: dts: add dts files for Hi3519
@ 2016-01-08 15:10 ` Russell King - ARM Linux
0 siblings, 0 replies; 103+ messages in thread
From: Russell King - ARM Linux @ 2016-01-08 15:10 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, khilman-QSEj5FYQhm4dnm+yROfE0A,
arnd-r2nGTMty4D4, olof-nZhT3qVonbNeoWH0uzbU5w,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A,
zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A,
bintian.wang-hv44wF8Li93QT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
yanhaifeng-C8/M+/jPZTeaMJb+Lgu22Q,
yanghongwei-C8/M+/jPZTeaMJb+Lgu22Q,
suwenping-C8/M+/jPZTeaMJb+Lgu22Q, ml.yang-C8/M+/jPZTeaMJb+Lgu22Q,
gaofei-C8/M+/jPZTeaMJb+Lgu22Q,
zhangzhenxing-C8/M+/jPZTeaMJb+Lgu22Q,
xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q
On Fri, Jan 08, 2016 at 10:16:40AM +0800, Jiancheng Xue wrote:
> + uart0: serial@12100000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x12100000 0x1000>;
> + interrupts = <0 4 4>;
Should the last digit there be IRQ_TYPE_LEVEL_HIGH (and same for the
other interrupts= after this?)
Thanks.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 6/6] ARM: dts: add dts files for Hi3519
@ 2016-01-08 15:10 ` Russell King - ARM Linux
0 siblings, 0 replies; 103+ messages in thread
From: Russell King - ARM Linux @ 2016-01-08 15:10 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 08, 2016 at 10:16:40AM +0800, Jiancheng Xue wrote:
> + uart0: serial at 12100000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x12100000 0x1000>;
> + interrupts = <0 4 4>;
Should the last digit there be IRQ_TYPE_LEVEL_HIGH (and same for the
other interrupts= after this?)
Thanks.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-08 2:16 ` Jiancheng Xue
@ 2016-01-08 21:04 ` Rob Herring
-1 siblings, 0 replies; 103+ messages in thread
From: Rob Herring @ 2016-01-08 21:04 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mturquette, sboyd, p.zabel, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Fri, Jan 08, 2016 at 10:16:39AM +0800, Jiancheng Xue wrote:
> Add device tree bindings for Hi3519 system controller.
>
> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
> ---
> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
This seems like it could be combined with other HiSi system controller
bindings if the compatible string is the only difference. But it is fine
like this:
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-08 21:04 ` Rob Herring
0 siblings, 0 replies; 103+ messages in thread
From: Rob Herring @ 2016-01-08 21:04 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 08, 2016 at 10:16:39AM +0800, Jiancheng Xue wrote:
> Add device tree bindings for Hi3519 system controller.
>
> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
> ---
> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
This seems like it could be combined with other HiSi system controller
bindings if the compatible string is the only difference. But it is fine
like this:
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-08 2:16 ` Jiancheng Xue
(?)
@ 2016-01-09 6:24 ` kbuild test robot
-1 siblings, 0 replies; 103+ messages in thread
From: kbuild test robot @ 2016-01-09 6:24 UTC (permalink / raw)
To: Jiancheng Xue
Cc: kbuild-all, mturquette, sboyd, p.zabel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, khilman, arnd, olof,
xuwei5, haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng,
Jiancheng Xue
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
Hi Jiancheng,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.4-rc8 next-20160108]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Jiancheng-Xue/ARM-hisi-Add-initial-support-including-clock-driver-for-Hi3519-soc/20160108-103510
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: arm-allmodconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "hisi_reset_init" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_register_gate" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_register_mux" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_register_fixed_rate" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_init" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 54589 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-09 6:24 ` kbuild test robot
0 siblings, 0 replies; 103+ messages in thread
From: kbuild test robot @ 2016-01-09 6:24 UTC (permalink / raw)
Cc: kbuild-all, mturquette, sboyd, p.zabel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, khilman, arnd, olof,
xuwei5, haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng,
Jiancheng Xue
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
Hi Jiancheng,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.4-rc8 next-20160108]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Jiancheng-Xue/ARM-hisi-Add-initial-support-including-clock-driver-for-Hi3519-soc/20160108-103510
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: arm-allmodconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "hisi_reset_init" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_register_gate" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_register_mux" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_register_fixed_rate" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_init" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 54589 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-09 6:24 ` kbuild test robot
0 siblings, 0 replies; 103+ messages in thread
From: kbuild test robot @ 2016-01-09 6:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jiancheng,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.4-rc8 next-20160108]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Jiancheng-Xue/ARM-hisi-Add-initial-support-including-clock-driver-for-Hi3519-soc/20160108-103510
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: arm-allmodconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "hisi_reset_init" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_register_gate" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_register_mux" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_register_fixed_rate" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
>> ERROR: "hisi_clk_init" [drivers/clk/hisilicon/clk-hi3519.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 54589 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160109/57ae82aa/attachment-0001.obj>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-08 2:16 ` Jiancheng Xue
@ 2016-01-09 15:33 ` Rob Herring
-1 siblings, 0 replies; 103+ messages in thread
From: Rob Herring @ 2016-01-09 15:33 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mturquette, sboyd, p.zabel, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Fri, Jan 08, 2016 at 10:16:35AM +0800, Jiancheng Xue wrote:
> The CRG(Clock and Reset Generator) block provides clock
> and reset signals for other modules in hi3519 soc.
>
> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
[...]
> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
> new file mode 100644
> index 0000000..72d3a7b0
> --- /dev/null
> +++ b/drivers/clk/hisilicon/clk-hi3519.c
> @@ -0,0 +1,105 @@
> +/*
> + * Hi3519 Clock Driver
> + *
> + * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <dt-bindings/clock/hi3519-clock.h>
> +#include <linux/delay.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +#include "clk.h"
> +#include "reset.h"
> +
> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
This is fragile because HI3519_EXT_CLKS will change every time you
add a clock to DT and means you have to keep the kernel and DT in sync.
I'd be less worried if your clock definitions were more complete, but
I'm guess the SOC has more than 19 clocks coming out of the clock
controller.
> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
> +
> +#define HI3519_NR_CLKS 128
You only have 29 clocks defined.
> +#ifndef __DTS_HI3519_CLOCK_H
> +#define __DTS_HI3519_CLOCK_H
> +
> +#define HI3519_FIXED_3M 1
> +#define HI3519_FMC_CLK 2
> +#define HI3519_USB2_BUS_CLK 3
> +#define HI3519_USB2_PORT_CLK 4
> +#define HI3519_USB3_CLK 5
> +#define HI3519_ETH_PHY_CLK 6
> +#define HI3519_ETH_MAC_CLK 7
> +#define HI3519_ETH_MACIF_CLK 8
> +#define HI3519_PWM_CLK 9
> +#define HI3519_DMA_CLK 10
> +#define HI3519_SPI0_CLK 11
> +#define HI3519_SPI1_CLK 12
> +#define HI3519_SPI2_CLK 13
> +#define HI3519_IR_CLK 14
> +#define HI3519_UART0_CLK 15
> +#define HI3519_UART1_CLK 16
> +#define HI3519_UART2_CLK 17
> +#define HI3519_UART3_CLK 18
> +#define HI3519_UART4_CLK 19
> +
> +#define HI3519_EXT_CLKS 19
> +
> +#endif /* __DTS_HI3519_CLOCK_H */
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-09 15:33 ` Rob Herring
0 siblings, 0 replies; 103+ messages in thread
From: Rob Herring @ 2016-01-09 15:33 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 08, 2016 at 10:16:35AM +0800, Jiancheng Xue wrote:
> The CRG(Clock and Reset Generator) block provides clock
> and reset signals for other modules in hi3519 soc.
>
> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
[...]
> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
> new file mode 100644
> index 0000000..72d3a7b0
> --- /dev/null
> +++ b/drivers/clk/hisilicon/clk-hi3519.c
> @@ -0,0 +1,105 @@
> +/*
> + * Hi3519 Clock Driver
> + *
> + * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <dt-bindings/clock/hi3519-clock.h>
> +#include <linux/delay.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +#include "clk.h"
> +#include "reset.h"
> +
> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
This is fragile because HI3519_EXT_CLKS will change every time you
add a clock to DT and means you have to keep the kernel and DT in sync.
I'd be less worried if your clock definitions were more complete, but
I'm guess the SOC has more than 19 clocks coming out of the clock
controller.
> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
> +
> +#define HI3519_NR_CLKS 128
You only have 29 clocks defined.
> +#ifndef __DTS_HI3519_CLOCK_H
> +#define __DTS_HI3519_CLOCK_H
> +
> +#define HI3519_FIXED_3M 1
> +#define HI3519_FMC_CLK 2
> +#define HI3519_USB2_BUS_CLK 3
> +#define HI3519_USB2_PORT_CLK 4
> +#define HI3519_USB3_CLK 5
> +#define HI3519_ETH_PHY_CLK 6
> +#define HI3519_ETH_MAC_CLK 7
> +#define HI3519_ETH_MACIF_CLK 8
> +#define HI3519_PWM_CLK 9
> +#define HI3519_DMA_CLK 10
> +#define HI3519_SPI0_CLK 11
> +#define HI3519_SPI1_CLK 12
> +#define HI3519_SPI2_CLK 13
> +#define HI3519_IR_CLK 14
> +#define HI3519_UART0_CLK 15
> +#define HI3519_UART1_CLK 16
> +#define HI3519_UART2_CLK 17
> +#define HI3519_UART3_CLK 18
> +#define HI3519_UART4_CLK 19
> +
> +#define HI3519_EXT_CLKS 19
> +
> +#endif /* __DTS_HI3519_CLOCK_H */
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 6/6] ARM: dts: add dts files for Hi3519
2016-01-08 15:10 ` Russell King - ARM Linux
(?)
@ 2016-01-11 2:05 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 2:05 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hello Russell,
On 2016/1/8 23:10, Russell King - ARM Linux wrote:
> On Fri, Jan 08, 2016 at 10:16:40AM +0800, Jiancheng Xue wrote:
>> + uart0: serial@12100000 {
>> + compatible = "arm,pl011", "arm,primecell";
>> + reg = <0x12100000 0x1000>;
>> + interrupts = <0 4 4>;
>
> Should the last digit there be IRQ_TYPE_LEVEL_HIGH (and same for the
> other interrupts= after this?)
>
> Thanks.
>
I'll include <dt-bindings/interrupt-controller/arm-gic.h> and use
IRQ_TYPE_LEVEL_HIGH instead. The interrupts specifier will be wrote
like this "interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;".
Thank you.
Jiancheng
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 6/6] ARM: dts: add dts files for Hi3519
@ 2016-01-11 2:05 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 2:05 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hello Russell,
On 2016/1/8 23:10, Russell King - ARM Linux wrote:
> On Fri, Jan 08, 2016 at 10:16:40AM +0800, Jiancheng Xue wrote:
>> + uart0: serial@12100000 {
>> + compatible = "arm,pl011", "arm,primecell";
>> + reg = <0x12100000 0x1000>;
>> + interrupts = <0 4 4>;
>
> Should the last digit there be IRQ_TYPE_LEVEL_HIGH (and same for the
> other interrupts= after this?)
>
> Thanks.
>
I'll include <dt-bindings/interrupt-controller/arm-gic.h> and use
IRQ_TYPE_LEVEL_HIGH instead. The interrupts specifier will be wrote
like this "interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;".
Thank you.
Jiancheng
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 6/6] ARM: dts: add dts files for Hi3519
@ 2016-01-11 2:05 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 2:05 UTC (permalink / raw)
To: linux-arm-kernel
Hello Russell,
On 2016/1/8 23:10, Russell King - ARM Linux wrote:
> On Fri, Jan 08, 2016 at 10:16:40AM +0800, Jiancheng Xue wrote:
>> + uart0: serial at 12100000 {
>> + compatible = "arm,pl011", "arm,primecell";
>> + reg = <0x12100000 0x1000>;
>> + interrupts = <0 4 4>;
>
> Should the last digit there be IRQ_TYPE_LEVEL_HIGH (and same for the
> other interrupts= after this?)
>
> Thanks.
>
I'll include <dt-bindings/interrupt-controller/arm-gic.h> and use
IRQ_TYPE_LEVEL_HIGH instead. The interrupts specifier will be wrote
like this "interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;".
Thank you.
Jiancheng
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 4/6] ARM: debug: add hi3519 debug uart
2016-01-08 15:08 ` Russell King - ARM Linux
(?)
@ 2016-01-11 2:32 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 2:32 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hello Russell,
On 2016/1/8 23:08, Russell King - ARM Linux wrote:
> On Fri, Jan 08, 2016 at 10:16:38AM +0800, Jiancheng Xue wrote:
>> @@ -1449,6 +1457,7 @@ config DEBUG_UART_PHYS
>> default 0xf7fc9000 if DEBUG_BERLIN_UART
>> default 0xf8b00000 if DEBUG_HIX5HD2_UART
>> default 0xf991e000 if DEBUG_QCOM_UARTDM
>> + default 0x12100000 if DEBUG_HI3519_UART
>> default 0xfcb00000 if DEBUG_HI3620_UART
>> default 0xfd883000 if DEBUG_ALPINE_UART0
>> default 0xfe800000 if ARCH_IOP32X
>
> Please insert at the appropriate location - examination of the list
> of defaults will show that it's sorted numerically, please keep this
> sorted numerically.
>
OK. Thank you!
>> @@ -1529,6 +1538,7 @@ config DEBUG_UART_VIRT
>> default 0xfe230000 if DEBUG_PICOXCELL_UART
>> default 0xfe300000 if DEBUG_BCM_KONA_UART
>> default 0xfe800000 if ARCH_IOP32X
>> + default 0xfef00000 if DEBUG_HI3519_UART
>> default 0xfeb00000 if DEBUG_HI3620_UART || DEBUG_HIX5HD2_UART
>> default 0xfeb24000 if DEBUG_RK3X_UART0
>> default 0xfeb26000 if DEBUG_RK3X_UART1
>
> Same for here.
>
> Thanks.
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 4/6] ARM: debug: add hi3519 debug uart
@ 2016-01-11 2:32 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 2:32 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: mark.rutland, suwenping, mturquette, bintian.wang,
haojian.zhuang, linux-clk, pawel.moll, xuwei5, zhangfei.gao,
zhangzhenxing, devicetree, khilman, arnd, ijc+devicetree,
yanhaifeng, ml.yang, robh+dt, xuejiancheng, linux-arm-kernel,
sboyd, linux-kernel, gaofei, p.zabel, galak, olof, yanghongwei
Hello Russell,
On 2016/1/8 23:08, Russell King - ARM Linux wrote:
> On Fri, Jan 08, 2016 at 10:16:38AM +0800, Jiancheng Xue wrote:
>> @@ -1449,6 +1457,7 @@ config DEBUG_UART_PHYS
>> default 0xf7fc9000 if DEBUG_BERLIN_UART
>> default 0xf8b00000 if DEBUG_HIX5HD2_UART
>> default 0xf991e000 if DEBUG_QCOM_UARTDM
>> + default 0x12100000 if DEBUG_HI3519_UART
>> default 0xfcb00000 if DEBUG_HI3620_UART
>> default 0xfd883000 if DEBUG_ALPINE_UART0
>> default 0xfe800000 if ARCH_IOP32X
>
> Please insert at the appropriate location - examination of the list
> of defaults will show that it's sorted numerically, please keep this
> sorted numerically.
>
OK. Thank you!
>> @@ -1529,6 +1538,7 @@ config DEBUG_UART_VIRT
>> default 0xfe230000 if DEBUG_PICOXCELL_UART
>> default 0xfe300000 if DEBUG_BCM_KONA_UART
>> default 0xfe800000 if ARCH_IOP32X
>> + default 0xfef00000 if DEBUG_HI3519_UART
>> default 0xfeb00000 if DEBUG_HI3620_UART || DEBUG_HIX5HD2_UART
>> default 0xfeb24000 if DEBUG_RK3X_UART0
>> default 0xfeb26000 if DEBUG_RK3X_UART1
>
> Same for here.
>
> Thanks.
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 4/6] ARM: debug: add hi3519 debug uart
@ 2016-01-11 2:32 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 2:32 UTC (permalink / raw)
To: linux-arm-kernel
Hello Russell,
On 2016/1/8 23:08, Russell King - ARM Linux wrote:
> On Fri, Jan 08, 2016 at 10:16:38AM +0800, Jiancheng Xue wrote:
>> @@ -1449,6 +1457,7 @@ config DEBUG_UART_PHYS
>> default 0xf7fc9000 if DEBUG_BERLIN_UART
>> default 0xf8b00000 if DEBUG_HIX5HD2_UART
>> default 0xf991e000 if DEBUG_QCOM_UARTDM
>> + default 0x12100000 if DEBUG_HI3519_UART
>> default 0xfcb00000 if DEBUG_HI3620_UART
>> default 0xfd883000 if DEBUG_ALPINE_UART0
>> default 0xfe800000 if ARCH_IOP32X
>
> Please insert at the appropriate location - examination of the list
> of defaults will show that it's sorted numerically, please keep this
> sorted numerically.
>
OK. Thank you!
>> @@ -1529,6 +1538,7 @@ config DEBUG_UART_VIRT
>> default 0xfe230000 if DEBUG_PICOXCELL_UART
>> default 0xfe300000 if DEBUG_BCM_KONA_UART
>> default 0xfe800000 if ARCH_IOP32X
>> + default 0xfef00000 if DEBUG_HI3519_UART
>> default 0xfeb00000 if DEBUG_HI3620_UART || DEBUG_HIX5HD2_UART
>> default 0xfeb24000 if DEBUG_RK3X_UART0
>> default 0xfeb26000 if DEBUG_RK3X_UART1
>
> Same for here.
>
> Thanks.
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-09 15:33 ` Rob Herring
(?)
@ 2016-01-11 3:47 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 3:47 UTC (permalink / raw)
To: Rob Herring
Cc: mturquette, sboyd, p.zabel, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hi Rob,
On 2016/1/9 23:33, Rob Herring wrote:
> On Fri, Jan 08, 2016 at 10:16:35AM +0800, Jiancheng Xue wrote:
>> The CRG(Clock and Reset Generator) block provides clock
>> and reset signals for other modules in hi3519 soc.
>>
>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>
> [...]
>
>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>> new file mode 100644
>> index 0000000..72d3a7b0
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>> @@ -0,0 +1,105 @@
>> +/*
>> + * Hi3519 Clock Driver
>> + *
>> + * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <dt-bindings/clock/hi3519-clock.h>
>> +#include <linux/delay.h>
>> +#include <linux/of_address.h>
>> +#include <linux/slab.h>
>> +#include "clk.h"
>> +#include "reset.h"
>> +
>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>
> This is fragile because HI3519_EXT_CLKS will change every time you
> add a clock to DT and means you have to keep the kernel and DT in sync.
>
The dependence is indeed unneeded. Thank you.
> I'd be less worried if your clock definitions were more complete, but
> I'm guess the SOC has more than 19 clocks coming out of the clock
> controller.
>
You are right. Some clocks in the SOC are not defined in this patch. Because
there is no plan to upstream those blocks drivers using these clocks. The clocks
defined in this file will not referred by the DT. So it's also not proper to
put these definitions into the dt-bingdings header file.
I will change HI3519_EXT_CLKS to a large number to make sure that enough space
is reserved for external clocks? Is it OK?
Your advise will be appreciated. Thank you.
>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>> +
>> +#define HI3519_NR_CLKS 128
>
> You only have 29 clocks defined.
>
>
>> +#ifndef __DTS_HI3519_CLOCK_H
>> +#define __DTS_HI3519_CLOCK_H
>> +
>> +#define HI3519_FIXED_3M 1
>> +#define HI3519_FMC_CLK 2
>> +#define HI3519_USB2_BUS_CLK 3
>> +#define HI3519_USB2_PORT_CLK 4
>> +#define HI3519_USB3_CLK 5
>> +#define HI3519_ETH_PHY_CLK 6
>> +#define HI3519_ETH_MAC_CLK 7
>> +#define HI3519_ETH_MACIF_CLK 8
>> +#define HI3519_PWM_CLK 9
>> +#define HI3519_DMA_CLK 10
>> +#define HI3519_SPI0_CLK 11
>> +#define HI3519_SPI1_CLK 12
>> +#define HI3519_SPI2_CLK 13
>> +#define HI3519_IR_CLK 14
>> +#define HI3519_UART0_CLK 15
>> +#define HI3519_UART1_CLK 16
>> +#define HI3519_UART2_CLK 17
>> +#define HI3519_UART3_CLK 18
>> +#define HI3519_UART4_CLK 19
>> +
>> +#define HI3519_EXT_CLKS 19
>> +
>> +#endif /* __DTS_HI3519_CLOCK_H */
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-11 3:47 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 3:47 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, suwenping, mturquette, bintian.wang,
haojian.zhuang, linux-clk, linux, pawel.moll, xuwei5,
zhangfei.gao, zhangzhenxing, devicetree, khilman, arnd,
ijc+devicetree, yanhaifeng, ml.yang, xuejiancheng,
linux-arm-kernel, sboyd, linux-kernel, gaofei, p.zabel, galak,
olof, yanghongwei
Hi Rob,
On 2016/1/9 23:33, Rob Herring wrote:
> On Fri, Jan 08, 2016 at 10:16:35AM +0800, Jiancheng Xue wrote:
>> The CRG(Clock and Reset Generator) block provides clock
>> and reset signals for other modules in hi3519 soc.
>>
>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>
> [...]
>
>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>> new file mode 100644
>> index 0000000..72d3a7b0
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>> @@ -0,0 +1,105 @@
>> +/*
>> + * Hi3519 Clock Driver
>> + *
>> + * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <dt-bindings/clock/hi3519-clock.h>
>> +#include <linux/delay.h>
>> +#include <linux/of_address.h>
>> +#include <linux/slab.h>
>> +#include "clk.h"
>> +#include "reset.h"
>> +
>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>
> This is fragile because HI3519_EXT_CLKS will change every time you
> add a clock to DT and means you have to keep the kernel and DT in sync.
>
The dependence is indeed unneeded. Thank you.
> I'd be less worried if your clock definitions were more complete, but
> I'm guess the SOC has more than 19 clocks coming out of the clock
> controller.
>
You are right. Some clocks in the SOC are not defined in this patch. Because
there is no plan to upstream those blocks drivers using these clocks. The clocks
defined in this file will not referred by the DT. So it's also not proper to
put these definitions into the dt-bingdings header file.
I will change HI3519_EXT_CLKS to a large number to make sure that enough space
is reserved for external clocks? Is it OK?
Your advise will be appreciated. Thank you.
>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>> +
>> +#define HI3519_NR_CLKS 128
>
> You only have 29 clocks defined.
>
>
>> +#ifndef __DTS_HI3519_CLOCK_H
>> +#define __DTS_HI3519_CLOCK_H
>> +
>> +#define HI3519_FIXED_3M 1
>> +#define HI3519_FMC_CLK 2
>> +#define HI3519_USB2_BUS_CLK 3
>> +#define HI3519_USB2_PORT_CLK 4
>> +#define HI3519_USB3_CLK 5
>> +#define HI3519_ETH_PHY_CLK 6
>> +#define HI3519_ETH_MAC_CLK 7
>> +#define HI3519_ETH_MACIF_CLK 8
>> +#define HI3519_PWM_CLK 9
>> +#define HI3519_DMA_CLK 10
>> +#define HI3519_SPI0_CLK 11
>> +#define HI3519_SPI1_CLK 12
>> +#define HI3519_SPI2_CLK 13
>> +#define HI3519_IR_CLK 14
>> +#define HI3519_UART0_CLK 15
>> +#define HI3519_UART1_CLK 16
>> +#define HI3519_UART2_CLK 17
>> +#define HI3519_UART3_CLK 18
>> +#define HI3519_UART4_CLK 19
>> +
>> +#define HI3519_EXT_CLKS 19
>> +
>> +#endif /* __DTS_HI3519_CLOCK_H */
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-11 3:47 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 3:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
On 2016/1/9 23:33, Rob Herring wrote:
> On Fri, Jan 08, 2016 at 10:16:35AM +0800, Jiancheng Xue wrote:
>> The CRG(Clock and Reset Generator) block provides clock
>> and reset signals for other modules in hi3519 soc.
>>
>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>
> [...]
>
>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>> new file mode 100644
>> index 0000000..72d3a7b0
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>> @@ -0,0 +1,105 @@
>> +/*
>> + * Hi3519 Clock Driver
>> + *
>> + * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <dt-bindings/clock/hi3519-clock.h>
>> +#include <linux/delay.h>
>> +#include <linux/of_address.h>
>> +#include <linux/slab.h>
>> +#include "clk.h"
>> +#include "reset.h"
>> +
>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>
> This is fragile because HI3519_EXT_CLKS will change every time you
> add a clock to DT and means you have to keep the kernel and DT in sync.
>
The dependence is indeed unneeded. Thank you.
> I'd be less worried if your clock definitions were more complete, but
> I'm guess the SOC has more than 19 clocks coming out of the clock
> controller.
>
You are right. Some clocks in the SOC are not defined in this patch. Because
there is no plan to upstream those blocks drivers using these clocks. The clocks
defined in this file will not referred by the DT. So it's also not proper to
put these definitions into the dt-bingdings header file.
I will change HI3519_EXT_CLKS to a large number to make sure that enough space
is reserved for external clocks? Is it OK?
Your advise will be appreciated. Thank you.
>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>> +
>> +#define HI3519_NR_CLKS 128
>
> You only have 29 clocks defined.
>
>
>> +#ifndef __DTS_HI3519_CLOCK_H
>> +#define __DTS_HI3519_CLOCK_H
>> +
>> +#define HI3519_FIXED_3M 1
>> +#define HI3519_FMC_CLK 2
>> +#define HI3519_USB2_BUS_CLK 3
>> +#define HI3519_USB2_PORT_CLK 4
>> +#define HI3519_USB3_CLK 5
>> +#define HI3519_ETH_PHY_CLK 6
>> +#define HI3519_ETH_MAC_CLK 7
>> +#define HI3519_ETH_MACIF_CLK 8
>> +#define HI3519_PWM_CLK 9
>> +#define HI3519_DMA_CLK 10
>> +#define HI3519_SPI0_CLK 11
>> +#define HI3519_SPI1_CLK 12
>> +#define HI3519_SPI2_CLK 13
>> +#define HI3519_IR_CLK 14
>> +#define HI3519_UART0_CLK 15
>> +#define HI3519_UART1_CLK 16
>> +#define HI3519_UART2_CLK 17
>> +#define HI3519_UART3_CLK 18
>> +#define HI3519_UART4_CLK 19
>> +
>> +#define HI3519_EXT_CLKS 19
>> +
>> +#endif /* __DTS_HI3519_CLOCK_H */
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-08 2:16 ` Jiancheng Xue
@ 2016-01-11 5:48 ` Lee Jones
-1 siblings, 0 replies; 103+ messages in thread
From: Lee Jones @ 2016-01-11 5:48 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Fri, 08 Jan 2016, Jiancheng Xue wrote:
> Add device tree bindings for Hi3519 system controller.
>
> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
> ---
> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
I have this patch, but none of the others in the set, thus I am
lacking context.
> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
> new file mode 100644
> index 0000000..115c5be
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
> @@ -0,0 +1,14 @@
> +* Hisilicon Hi3519 System Controller Block
> +
> +This bindings use the following binding:
> +Documentation/devicetree/bindings/mfd/syscon.txt
> +
> +Required properties:
> +- compatible: "hisilicon,hi3519-sysctrl".
> +- reg: the register region of this block
> +
> +Examples:
> +sysctrl: system-controller@12010000 {
> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
> + reg = <0x12010000 0x1000>;
> +};
There is no requirement (nor want) for binding documents where the
given device is simply using highly generic bindings. This just
amounts to churn.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-11 5:48 ` Lee Jones
0 siblings, 0 replies; 103+ messages in thread
From: Lee Jones @ 2016-01-11 5:48 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 08 Jan 2016, Jiancheng Xue wrote:
> Add device tree bindings for Hi3519 system controller.
>
> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
> ---
> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
I have this patch, but none of the others in the set, thus I am
lacking context.
> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
> new file mode 100644
> index 0000000..115c5be
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
> @@ -0,0 +1,14 @@
> +* Hisilicon Hi3519 System Controller Block
> +
> +This bindings use the following binding:
> +Documentation/devicetree/bindings/mfd/syscon.txt
> +
> +Required properties:
> +- compatible: "hisilicon,hi3519-sysctrl".
> +- reg: the register region of this block
> +
> +Examples:
> +sysctrl: system-controller at 12010000 {
> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
> + reg = <0x12010000 0x1000>;
> +};
There is no requirement (nor want) for binding documents where the
given device is simply using highly generic bindings. This just
amounts to churn.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-11 5:48 ` Lee Jones
(?)
@ 2016-01-11 7:50 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 7:50 UTC (permalink / raw)
To: Lee Jones
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hi Lee Jones,
Thanks for your comments.
On 2016/1/11 13:48, Lee Jones wrote:
> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>
>> Add device tree bindings for Hi3519 system controller.
>>
>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>> ---
>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>
> I have this patch, but none of the others in the set, thus I am
> lacking context.
>
I can forward other patches in the set to you. Thank you.
>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>> new file mode 100644
>> index 0000000..115c5be
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>> @@ -0,0 +1,14 @@
>> +* Hisilicon Hi3519 System Controller Block
>> +
>> +This bindings use the following binding:
>> +Documentation/devicetree/bindings/mfd/syscon.txt
>> +
>> +Required properties:
>> +- compatible: "hisilicon,hi3519-sysctrl".
>> +- reg: the register region of this block
>> +
>> +Examples:
>> +sysctrl: system-controller@12010000 {
>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>> + reg = <0x12010000 0x1000>;
>> +};
>
> There is no requirement (nor want) for binding documents where the
> given device is simply using highly generic bindings. This just
> amounts to churn.
>
This block is specific for Hi3519 SOC, and may has its own driver.
So I think it's better to keep this binding.
Jiancheng
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-11 7:50 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 7:50 UTC (permalink / raw)
To: Lee Jones
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hi Lee Jones,
Thanks for your comments.
On 2016/1/11 13:48, Lee Jones wrote:
> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>
>> Add device tree bindings for Hi3519 system controller.
>>
>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>> ---
>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>
> I have this patch, but none of the others in the set, thus I am
> lacking context.
>
I can forward other patches in the set to you. Thank you.
>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>> new file mode 100644
>> index 0000000..115c5be
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>> @@ -0,0 +1,14 @@
>> +* Hisilicon Hi3519 System Controller Block
>> +
>> +This bindings use the following binding:
>> +Documentation/devicetree/bindings/mfd/syscon.txt
>> +
>> +Required properties:
>> +- compatible: "hisilicon,hi3519-sysctrl".
>> +- reg: the register region of this block
>> +
>> +Examples:
>> +sysctrl: system-controller@12010000 {
>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>> + reg = <0x12010000 0x1000>;
>> +};
>
> There is no requirement (nor want) for binding documents where the
> given device is simply using highly generic bindings. This just
> amounts to churn.
>
This block is specific for Hi3519 SOC, and may has its own driver.
So I think it's better to keep this binding.
Jiancheng
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-11 7:50 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-11 7:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lee Jones,
Thanks for your comments.
On 2016/1/11 13:48, Lee Jones wrote:
> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>
>> Add device tree bindings for Hi3519 system controller.
>>
>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>> ---
>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>
> I have this patch, but none of the others in the set, thus I am
> lacking context.
>
I can forward other patches in the set to you. Thank you.
>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>> new file mode 100644
>> index 0000000..115c5be
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>> @@ -0,0 +1,14 @@
>> +* Hisilicon Hi3519 System Controller Block
>> +
>> +This bindings use the following binding:
>> +Documentation/devicetree/bindings/mfd/syscon.txt
>> +
>> +Required properties:
>> +- compatible: "hisilicon,hi3519-sysctrl".
>> +- reg: the register region of this block
>> +
>> +Examples:
>> +sysctrl: system-controller at 12010000 {
>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>> + reg = <0x12010000 0x1000>;
>> +};
>
> There is no requirement (nor want) for binding documents where the
> given device is simply using highly generic bindings. This just
> amounts to churn.
>
This block is specific for Hi3519 SOC, and may has its own driver.
So I think it's better to keep this binding.
Jiancheng
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-11 7:50 ` xuejiancheng
@ 2016-01-11 8:55 ` Lee Jones
-1 siblings, 0 replies; 103+ messages in thread
From: Lee Jones @ 2016-01-11 8:55 UTC (permalink / raw)
To: xuejiancheng
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Mon, 11 Jan 2016, xuejiancheng wrote:
> On 2016/1/11 13:48, Lee Jones wrote:
> > On Fri, 08 Jan 2016, Jiancheng Xue wrote:
> >
> >> Add device tree bindings for Hi3519 system controller.
> >>
> >> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
> >> ---
> >> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
> >> 1 file changed, 14 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
> >
> > I have this patch, but none of the others in the set, thus I am
> > lacking context.
> >
> I can forward other patches in the set to you. Thank you.
>
> >> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >> new file mode 100644
> >> index 0000000..115c5be
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >> @@ -0,0 +1,14 @@
> >> +* Hisilicon Hi3519 System Controller Block
> >> +
> >> +This bindings use the following binding:
> >> +Documentation/devicetree/bindings/mfd/syscon.txt
> >> +
> >> +Required properties:
> >> +- compatible: "hisilicon,hi3519-sysctrl".
> >> +- reg: the register region of this block
> >> +
> >> +Examples:
> >> +sysctrl: system-controller@12010000 {
> >> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
> >> + reg = <0x12010000 0x1000>;
> >> +};
> >
> > There is no requirement (nor want) for binding documents where the
> > given device is simply using highly generic bindings. This just
> > amounts to churn.
> >
> This block is specific for Hi3519 SOC, and may has its own driver.
Does it have its own driver currently?
> So I think it's better to keep this binding.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-11 8:55 ` Lee Jones
0 siblings, 0 replies; 103+ messages in thread
From: Lee Jones @ 2016-01-11 8:55 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 11 Jan 2016, xuejiancheng wrote:
> On 2016/1/11 13:48, Lee Jones wrote:
> > On Fri, 08 Jan 2016, Jiancheng Xue wrote:
> >
> >> Add device tree bindings for Hi3519 system controller.
> >>
> >> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
> >> ---
> >> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
> >> 1 file changed, 14 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
> >
> > I have this patch, but none of the others in the set, thus I am
> > lacking context.
> >
> I can forward other patches in the set to you. Thank you.
>
> >> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >> new file mode 100644
> >> index 0000000..115c5be
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >> @@ -0,0 +1,14 @@
> >> +* Hisilicon Hi3519 System Controller Block
> >> +
> >> +This bindings use the following binding:
> >> +Documentation/devicetree/bindings/mfd/syscon.txt
> >> +
> >> +Required properties:
> >> +- compatible: "hisilicon,hi3519-sysctrl".
> >> +- reg: the register region of this block
> >> +
> >> +Examples:
> >> +sysctrl: system-controller at 12010000 {
> >> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
> >> + reg = <0x12010000 0x1000>;
> >> +};
> >
> > There is no requirement (nor want) for binding documents where the
> > given device is simply using highly generic bindings. This just
> > amounts to churn.
> >
> This block is specific for Hi3519 SOC, and may has its own driver.
Does it have its own driver currently?
> So I think it's better to keep this binding.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-11 8:55 ` Lee Jones
(?)
@ 2016-01-12 1:35 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-12 1:35 UTC (permalink / raw)
To: Lee Jones
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On 2016/1/11 16:55, Lee Jones wrote:
> On Mon, 11 Jan 2016, xuejiancheng wrote:
>> On 2016/1/11 13:48, Lee Jones wrote:
>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>>>
>>>> Add device tree bindings for Hi3519 system controller.
>>>>
>>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>>>> ---
>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>>>> 1 file changed, 14 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>>>
>>> I have this patch, but none of the others in the set, thus I am
>>> lacking context.
>>>
>> I can forward other patches in the set to you. Thank you.
>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>> new file mode 100644
>>>> index 0000000..115c5be
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>> @@ -0,0 +1,14 @@
>>>> +* Hisilicon Hi3519 System Controller Block
>>>> +
>>>> +This bindings use the following binding:
>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
>>>> +
>>>> +Required properties:
>>>> +- compatible: "hisilicon,hi3519-sysctrl".
>>>> +- reg: the register region of this block
>>>> +
>>>> +Examples:
>>>> +sysctrl: system-controller@12010000 {
>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>> + reg = <0x12010000 0x1000>;
>>>> +};
>>>
>>> There is no requirement (nor want) for binding documents where the
>>> given device is simply using highly generic bindings. This just
>>> amounts to churn.
>>>
>> This block is specific for Hi3519 SOC, and may has its own driver.
>
> Does it have its own driver currently?
>
Not yet.
Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
with the SOC name. This binding is just used for describing the compatible string now.
When more functions on hi3519 SOC are added later, the specific driver will be also
needed.
>> So I think it's better to keep this binding.
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-12 1:35 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-12 1:35 UTC (permalink / raw)
To: Lee Jones
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, linux-lFZ/pmaqli7XmaaqVzeoHQ,
khilman-QSEj5FYQhm4dnm+yROfE0A, arnd-r2nGTMty4D4,
olof-nZhT3qVonbNeoWH0uzbU5w, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A,
zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A,
bintian.wang-hv44wF8Li93QT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
yanhaifeng-C8/M+/jPZTeaMJb+Lgu22Q,
yanghongwei-C8/M+/jPZTeaMJb+Lgu22Q,
suwenping-C8/M+/jPZTeaMJb+Lgu22Q, ml.yang-C8/M+/jPZTeaMJb+Lgu22Q,
gaofei-C8/M+/jPZTeaMJb+Lgu22Q,
zhangzhenxing-C8/M+/jPZTeaMJb+Lgu22Q,
xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q
On 2016/1/11 16:55, Lee Jones wrote:
> On Mon, 11 Jan 2016, xuejiancheng wrote:
>> On 2016/1/11 13:48, Lee Jones wrote:
>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>>>
>>>> Add device tree bindings for Hi3519 system controller.
>>>>
>>>> Signed-off-by: Jiancheng Xue <xuejiancheng-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>>>> 1 file changed, 14 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>>>
>>> I have this patch, but none of the others in the set, thus I am
>>> lacking context.
>>>
>> I can forward other patches in the set to you. Thank you.
>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>> new file mode 100644
>>>> index 0000000..115c5be
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>> @@ -0,0 +1,14 @@
>>>> +* Hisilicon Hi3519 System Controller Block
>>>> +
>>>> +This bindings use the following binding:
>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
>>>> +
>>>> +Required properties:
>>>> +- compatible: "hisilicon,hi3519-sysctrl".
>>>> +- reg: the register region of this block
>>>> +
>>>> +Examples:
>>>> +sysctrl: system-controller@12010000 {
>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>> + reg = <0x12010000 0x1000>;
>>>> +};
>>>
>>> There is no requirement (nor want) for binding documents where the
>>> given device is simply using highly generic bindings. This just
>>> amounts to churn.
>>>
>> This block is specific for Hi3519 SOC, and may has its own driver.
>
> Does it have its own driver currently?
>
Not yet.
Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
with the SOC name. This binding is just used for describing the compatible string now.
When more functions on hi3519 SOC are added later, the specific driver will be also
needed.
>> So I think it's better to keep this binding.
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-12 1:35 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-12 1:35 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/11 16:55, Lee Jones wrote:
> On Mon, 11 Jan 2016, xuejiancheng wrote:
>> On 2016/1/11 13:48, Lee Jones wrote:
>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>>>
>>>> Add device tree bindings for Hi3519 system controller.
>>>>
>>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>>>> ---
>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>>>> 1 file changed, 14 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>>>
>>> I have this patch, but none of the others in the set, thus I am
>>> lacking context.
>>>
>> I can forward other patches in the set to you. Thank you.
>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>> new file mode 100644
>>>> index 0000000..115c5be
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>> @@ -0,0 +1,14 @@
>>>> +* Hisilicon Hi3519 System Controller Block
>>>> +
>>>> +This bindings use the following binding:
>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
>>>> +
>>>> +Required properties:
>>>> +- compatible: "hisilicon,hi3519-sysctrl".
>>>> +- reg: the register region of this block
>>>> +
>>>> +Examples:
>>>> +sysctrl: system-controller at 12010000 {
>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>> + reg = <0x12010000 0x1000>;
>>>> +};
>>>
>>> There is no requirement (nor want) for binding documents where the
>>> given device is simply using highly generic bindings. This just
>>> amounts to churn.
>>>
>> This block is specific for Hi3519 SOC, and may has its own driver.
>
> Does it have its own driver currently?
>
Not yet.
Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
with the SOC name. This binding is just used for describing the compatible string now.
When more functions on hi3519 SOC are added later, the specific driver will be also
needed.
>> So I think it's better to keep this binding.
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-12 1:35 ` xuejiancheng
@ 2016-01-12 7:41 ` Lee Jones
-1 siblings, 0 replies; 103+ messages in thread
From: Lee Jones @ 2016-01-12 7:41 UTC (permalink / raw)
To: xuejiancheng
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Tue, 12 Jan 2016, xuejiancheng wrote:
>
>
> On 2016/1/11 16:55, Lee Jones wrote:
> > On Mon, 11 Jan 2016, xuejiancheng wrote:
> >> On 2016/1/11 13:48, Lee Jones wrote:
> >>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
> >>>
> >>>> Add device tree bindings for Hi3519 system controller.
> >>>>
> >>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
> >>>> ---
> >>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
> >>>> 1 file changed, 14 insertions(+)
> >>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>
> >>> I have this patch, but none of the others in the set, thus I am
> >>> lacking context.
> >>>
> >> I can forward other patches in the set to you. Thank you.
> >>
> >>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>> new file mode 100644
> >>>> index 0000000..115c5be
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>> @@ -0,0 +1,14 @@
> >>>> +* Hisilicon Hi3519 System Controller Block
> >>>> +
> >>>> +This bindings use the following binding:
> >>>> +Documentation/devicetree/bindings/mfd/syscon.txt
> >>>> +
> >>>> +Required properties:
> >>>> +- compatible: "hisilicon,hi3519-sysctrl".
> >>>> +- reg: the register region of this block
> >>>> +
> >>>> +Examples:
> >>>> +sysctrl: system-controller@12010000 {
> >>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
> >>>> + reg = <0x12010000 0x1000>;
> >>>> +};
> >>>
> >>> There is no requirement (nor want) for binding documents where the
> >>> given device is simply using highly generic bindings. This just
> >>> amounts to churn.
> >>>
> >> This block is specific for Hi3519 SOC, and may has its own driver.
> >
> > Does it have its own driver currently?
> >
> Not yet.
> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
> with the SOC name. This binding is just used for describing the compatible string now.
> When more functions on hi3519 SOC are added later, the specific driver will be also
> needed.
Save this binding until it has more functionality. We here "I'll add
to this later" all too often.
> >> So I think it's better to keep this binding.
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-12 7:41 ` Lee Jones
0 siblings, 0 replies; 103+ messages in thread
From: Lee Jones @ 2016-01-12 7:41 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 12 Jan 2016, xuejiancheng wrote:
>
>
> On 2016/1/11 16:55, Lee Jones wrote:
> > On Mon, 11 Jan 2016, xuejiancheng wrote:
> >> On 2016/1/11 13:48, Lee Jones wrote:
> >>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
> >>>
> >>>> Add device tree bindings for Hi3519 system controller.
> >>>>
> >>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
> >>>> ---
> >>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
> >>>> 1 file changed, 14 insertions(+)
> >>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>
> >>> I have this patch, but none of the others in the set, thus I am
> >>> lacking context.
> >>>
> >> I can forward other patches in the set to you. Thank you.
> >>
> >>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>> new file mode 100644
> >>>> index 0000000..115c5be
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>> @@ -0,0 +1,14 @@
> >>>> +* Hisilicon Hi3519 System Controller Block
> >>>> +
> >>>> +This bindings use the following binding:
> >>>> +Documentation/devicetree/bindings/mfd/syscon.txt
> >>>> +
> >>>> +Required properties:
> >>>> +- compatible: "hisilicon,hi3519-sysctrl".
> >>>> +- reg: the register region of this block
> >>>> +
> >>>> +Examples:
> >>>> +sysctrl: system-controller at 12010000 {
> >>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
> >>>> + reg = <0x12010000 0x1000>;
> >>>> +};
> >>>
> >>> There is no requirement (nor want) for binding documents where the
> >>> given device is simply using highly generic bindings. This just
> >>> amounts to churn.
> >>>
> >> This block is specific for Hi3519 SOC, and may has its own driver.
> >
> > Does it have its own driver currently?
> >
> Not yet.
> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
> with the SOC name. This binding is just used for describing the compatible string now.
> When more functions on hi3519 SOC are added later, the specific driver will be also
> needed.
Save this binding until it has more functionality. We here "I'll add
to this later" all too often.
> >> So I think it's better to keep this binding.
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-12 7:41 ` Lee Jones
(?)
@ 2016-01-12 8:17 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-12 8:17 UTC (permalink / raw)
To: Lee Jones
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hello Lee,
On 2016/1/12 15:41, Lee Jones wrote:
> On Tue, 12 Jan 2016, xuejiancheng wrote:
>
>>
>>
>> On 2016/1/11 16:55, Lee Jones wrote:
>>> On Mon, 11 Jan 2016, xuejiancheng wrote:
>>>> On 2016/1/11 13:48, Lee Jones wrote:
>>>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>>>>>
>>>>>> Add device tree bindings for Hi3519 system controller.
>>>>>>
>>>>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>>>>>> 1 file changed, 14 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>
>>>>> I have this patch, but none of the others in the set, thus I am
>>>>> lacking context.
>>>>>
>>>> I can forward other patches in the set to you. Thank you.
>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..115c5be
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>> @@ -0,0 +1,14 @@
>>>>>> +* Hisilicon Hi3519 System Controller Block
>>>>>> +
>>>>>> +This bindings use the following binding:
>>>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible: "hisilicon,hi3519-sysctrl".
>>>>>> +- reg: the register region of this block
>>>>>> +
>>>>>> +Examples:
>>>>>> +sysctrl: system-controller@12010000 {
>>>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>>>> + reg = <0x12010000 0x1000>;
>>>>>> +};
>>>>>
>>>>> There is no requirement (nor want) for binding documents where the
>>>>> given device is simply using highly generic bindings. This just
>>>>> amounts to churn.
>>>>>
>>>> This block is specific for Hi3519 SOC, and may has its own driver.
>>>
>>> Does it have its own driver currently?
>>>
>> Not yet.
>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
>> with the SOC name. This binding is just used for describing the compatible string now.
>> When more functions on hi3519 SOC are added later, the specific driver will be also
>> needed.
>
> Save this binding until it has more functionality. We here "I'll add
> to this later" all too often.
>
In the hi3519.dtsi file, there is a system-controller device node described like below:
sysctrl: system-controller@12010000 {
compatible = "hisilicon,hi3519-sysctrl", "syscon";
reg = <0x12010000 0x1000>;
};
Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
compatible string?
If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
Could you give some suggestions? Thank you very much!
>>>> So I think it's better to keep this binding.
>>>
>>
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-12 8:17 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-12 8:17 UTC (permalink / raw)
To: Lee Jones
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, linux-lFZ/pmaqli7XmaaqVzeoHQ,
khilman-QSEj5FYQhm4dnm+yROfE0A, arnd-r2nGTMty4D4,
olof-nZhT3qVonbNeoWH0uzbU5w, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A,
zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A,
bintian.wang-hv44wF8Li93QT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
yanhaifeng-C8/M+/jPZTeaMJb+Lgu22Q,
yanghongwei-C8/M+/jPZTeaMJb+Lgu22Q,
suwenping-C8/M+/jPZTeaMJb+Lgu22Q, ml.yang-C8/M+/jPZTeaMJb+Lgu22Q,
gaofei-C8/M+/jPZTeaMJb+Lgu22Q,
zhangzhenxing-C8/M+/jPZTeaMJb+Lgu22Q,
xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q
Hello Lee,
On 2016/1/12 15:41, Lee Jones wrote:
> On Tue, 12 Jan 2016, xuejiancheng wrote:
>
>>
>>
>> On 2016/1/11 16:55, Lee Jones wrote:
>>> On Mon, 11 Jan 2016, xuejiancheng wrote:
>>>> On 2016/1/11 13:48, Lee Jones wrote:
>>>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>>>>>
>>>>>> Add device tree bindings for Hi3519 system controller.
>>>>>>
>>>>>> Signed-off-by: Jiancheng Xue <xuejiancheng-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>>>>>> 1 file changed, 14 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>
>>>>> I have this patch, but none of the others in the set, thus I am
>>>>> lacking context.
>>>>>
>>>> I can forward other patches in the set to you. Thank you.
>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..115c5be
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>> @@ -0,0 +1,14 @@
>>>>>> +* Hisilicon Hi3519 System Controller Block
>>>>>> +
>>>>>> +This bindings use the following binding:
>>>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible: "hisilicon,hi3519-sysctrl".
>>>>>> +- reg: the register region of this block
>>>>>> +
>>>>>> +Examples:
>>>>>> +sysctrl: system-controller@12010000 {
>>>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>>>> + reg = <0x12010000 0x1000>;
>>>>>> +};
>>>>>
>>>>> There is no requirement (nor want) for binding documents where the
>>>>> given device is simply using highly generic bindings. This just
>>>>> amounts to churn.
>>>>>
>>>> This block is specific for Hi3519 SOC, and may has its own driver.
>>>
>>> Does it have its own driver currently?
>>>
>> Not yet.
>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
>> with the SOC name. This binding is just used for describing the compatible string now.
>> When more functions on hi3519 SOC are added later, the specific driver will be also
>> needed.
>
> Save this binding until it has more functionality. We here "I'll add
> to this later" all too often.
>
In the hi3519.dtsi file, there is a system-controller device node described like below:
sysctrl: system-controller@12010000 {
compatible = "hisilicon,hi3519-sysctrl", "syscon";
reg = <0x12010000 0x1000>;
};
Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
compatible string?
If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
Could you give some suggestions? Thank you very much!
>>>> So I think it's better to keep this binding.
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-12 8:17 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-12 8:17 UTC (permalink / raw)
To: linux-arm-kernel
Hello Lee,
On 2016/1/12 15:41, Lee Jones wrote:
> On Tue, 12 Jan 2016, xuejiancheng wrote:
>
>>
>>
>> On 2016/1/11 16:55, Lee Jones wrote:
>>> On Mon, 11 Jan 2016, xuejiancheng wrote:
>>>> On 2016/1/11 13:48, Lee Jones wrote:
>>>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>>>>>
>>>>>> Add device tree bindings for Hi3519 system controller.
>>>>>>
>>>>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>>>>>> 1 file changed, 14 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>
>>>>> I have this patch, but none of the others in the set, thus I am
>>>>> lacking context.
>>>>>
>>>> I can forward other patches in the set to you. Thank you.
>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..115c5be
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>> @@ -0,0 +1,14 @@
>>>>>> +* Hisilicon Hi3519 System Controller Block
>>>>>> +
>>>>>> +This bindings use the following binding:
>>>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible: "hisilicon,hi3519-sysctrl".
>>>>>> +- reg: the register region of this block
>>>>>> +
>>>>>> +Examples:
>>>>>> +sysctrl: system-controller at 12010000 {
>>>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>>>> + reg = <0x12010000 0x1000>;
>>>>>> +};
>>>>>
>>>>> There is no requirement (nor want) for binding documents where the
>>>>> given device is simply using highly generic bindings. This just
>>>>> amounts to churn.
>>>>>
>>>> This block is specific for Hi3519 SOC, and may has its own driver.
>>>
>>> Does it have its own driver currently?
>>>
>> Not yet.
>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
>> with the SOC name. This binding is just used for describing the compatible string now.
>> When more functions on hi3519 SOC are added later, the specific driver will be also
>> needed.
>
> Save this binding until it has more functionality. We here "I'll add
> to this later" all too often.
>
In the hi3519.dtsi file, there is a system-controller device node described like below:
sysctrl: system-controller at 12010000 {
compatible = "hisilicon,hi3519-sysctrl", "syscon";
reg = <0x12010000 0x1000>;
};
Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
compatible string??
If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
Could you give some suggestions? Thank you very much!
>>>> So I think it's better to keep this binding.
>>>
>>
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-12 8:17 ` xuejiancheng
@ 2016-01-12 8:39 ` Lee Jones
-1 siblings, 0 replies; 103+ messages in thread
From: Lee Jones @ 2016-01-12 8:39 UTC (permalink / raw)
To: xuejiancheng
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Tue, 12 Jan 2016, xuejiancheng wrote:
> Hello Lee,
>
> On 2016/1/12 15:41, Lee Jones wrote:
> > On Tue, 12 Jan 2016, xuejiancheng wrote:
> >
> >>
> >>
> >> On 2016/1/11 16:55, Lee Jones wrote:
> >>> On Mon, 11 Jan 2016, xuejiancheng wrote:
> >>>> On 2016/1/11 13:48, Lee Jones wrote:
> >>>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
> >>>>>
> >>>>>> Add device tree bindings for Hi3519 system controller.
> >>>>>>
> >>>>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
> >>>>>> ---
> >>>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
> >>>>>> 1 file changed, 14 insertions(+)
> >>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>>>
> >>>>> I have this patch, but none of the others in the set, thus I am
> >>>>> lacking context.
> >>>>>
> >>>> I can forward other patches in the set to you. Thank you.
> >>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>>>> new file mode 100644
> >>>>>> index 0000000..115c5be
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>>>> @@ -0,0 +1,14 @@
> >>>>>> +* Hisilicon Hi3519 System Controller Block
> >>>>>> +
> >>>>>> +This bindings use the following binding:
> >>>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +- compatible: "hisilicon,hi3519-sysctrl".
> >>>>>> +- reg: the register region of this block
> >>>>>> +
> >>>>>> +Examples:
> >>>>>> +sysctrl: system-controller@12010000 {
> >>>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
> >>>>>> + reg = <0x12010000 0x1000>;
> >>>>>> +};
> >>>>>
> >>>>> There is no requirement (nor want) for binding documents where the
> >>>>> given device is simply using highly generic bindings. This just
> >>>>> amounts to churn.
> >>>>>
> >>>> This block is specific for Hi3519 SOC, and may has its own driver.
> >>>
> >>> Does it have its own driver currently?
> >>>
> >> Not yet.
> >> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
> >> with the SOC name. This binding is just used for describing the compatible string now.
> >> When more functions on hi3519 SOC are added later, the specific driver will be also
> >> needed.
> >
> > Save this binding until it has more functionality. We here "I'll add
> > to this later" all too often.
> >
>
> In the hi3519.dtsi file, there is a system-controller device node described like below:
> sysctrl: system-controller@12010000 {
> compatible = "hisilicon,hi3519-sysctrl", "syscon";
> reg = <0x12010000 0x1000>;
> };
> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
> compatible string?
Where is this compatible string _used_?
> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
> Could you give some suggestions? Thank you very much!
If you're not using the compatible i.e. the device doesn't have its
own driver yet, then there is no need to supply the binding at all, is
there?
> >>>> So I think it's better to keep this binding.
> >>>
> >>
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-12 8:39 ` Lee Jones
0 siblings, 0 replies; 103+ messages in thread
From: Lee Jones @ 2016-01-12 8:39 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 12 Jan 2016, xuejiancheng wrote:
> Hello Lee,
>
> On 2016/1/12 15:41, Lee Jones wrote:
> > On Tue, 12 Jan 2016, xuejiancheng wrote:
> >
> >>
> >>
> >> On 2016/1/11 16:55, Lee Jones wrote:
> >>> On Mon, 11 Jan 2016, xuejiancheng wrote:
> >>>> On 2016/1/11 13:48, Lee Jones wrote:
> >>>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
> >>>>>
> >>>>>> Add device tree bindings for Hi3519 system controller.
> >>>>>>
> >>>>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
> >>>>>> ---
> >>>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
> >>>>>> 1 file changed, 14 insertions(+)
> >>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>>>
> >>>>> I have this patch, but none of the others in the set, thus I am
> >>>>> lacking context.
> >>>>>
> >>>> I can forward other patches in the set to you. Thank you.
> >>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>>>> new file mode 100644
> >>>>>> index 0000000..115c5be
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
> >>>>>> @@ -0,0 +1,14 @@
> >>>>>> +* Hisilicon Hi3519 System Controller Block
> >>>>>> +
> >>>>>> +This bindings use the following binding:
> >>>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +- compatible: "hisilicon,hi3519-sysctrl".
> >>>>>> +- reg: the register region of this block
> >>>>>> +
> >>>>>> +Examples:
> >>>>>> +sysctrl: system-controller at 12010000 {
> >>>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
> >>>>>> + reg = <0x12010000 0x1000>;
> >>>>>> +};
> >>>>>
> >>>>> There is no requirement (nor want) for binding documents where the
> >>>>> given device is simply using highly generic bindings. This just
> >>>>> amounts to churn.
> >>>>>
> >>>> This block is specific for Hi3519 SOC, and may has its own driver.
> >>>
> >>> Does it have its own driver currently?
> >>>
> >> Not yet.
> >> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
> >> with the SOC name. This binding is just used for describing the compatible string now.
> >> When more functions on hi3519 SOC are added later, the specific driver will be also
> >> needed.
> >
> > Save this binding until it has more functionality. We here "I'll add
> > to this later" all too often.
> >
>
> In the hi3519.dtsi file, there is a system-controller device node described like below:
> sysctrl: system-controller at 12010000 {
> compatible = "hisilicon,hi3519-sysctrl", "syscon";
> reg = <0x12010000 0x1000>;
> };
> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
> compatible string??
Where is this compatible string _used_?
> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
> Could you give some suggestions? Thank you very much!
If you're not using the compatible i.e. the device doesn't have its
own driver yet, then there is no need to supply the binding at all, is
there?
> >>>> So I think it's better to keep this binding.
> >>>
> >>
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-12 8:39 ` Lee Jones
(?)
@ 2016-01-12 9:28 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-12 9:28 UTC (permalink / raw)
To: Lee Jones
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On 2016/1/12 16:39, Lee Jones wrote:
> On Tue, 12 Jan 2016, xuejiancheng wrote:
>
>> Hello Lee,
>>
>> On 2016/1/12 15:41, Lee Jones wrote:
>>> On Tue, 12 Jan 2016, xuejiancheng wrote:
>>>
>>>>
>>>>
>>>> On 2016/1/11 16:55, Lee Jones wrote:
>>>>> On Mon, 11 Jan 2016, xuejiancheng wrote:
>>>>>> On 2016/1/11 13:48, Lee Jones wrote:
>>>>>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>>>>>>>
>>>>>>>> Add device tree bindings for Hi3519 system controller.
>>>>>>>>
>>>>>>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>>>>>>>> ---
>>>>>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>>>>>>>> 1 file changed, 14 insertions(+)
>>>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>>>
>>>>>>> I have this patch, but none of the others in the set, thus I am
>>>>>>> lacking context.
>>>>>>>
>>>>>> I can forward other patches in the set to you. Thank you.
>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..115c5be
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>>>> @@ -0,0 +1,14 @@
>>>>>>>> +* Hisilicon Hi3519 System Controller Block
>>>>>>>> +
>>>>>>>> +This bindings use the following binding:
>>>>>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +- compatible: "hisilicon,hi3519-sysctrl".
>>>>>>>> +- reg: the register region of this block
>>>>>>>> +
>>>>>>>> +Examples:
>>>>>>>> +sysctrl: system-controller@12010000 {
>>>>>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>>>>>> + reg = <0x12010000 0x1000>;
>>>>>>>> +};
>>>>>>>
>>>>>>> There is no requirement (nor want) for binding documents where the
>>>>>>> given device is simply using highly generic bindings. This just
>>>>>>> amounts to churn.
>>>>>>>
>>>>>> This block is specific for Hi3519 SOC, and may has its own driver.
>>>>>
>>>>> Does it have its own driver currently?
>>>>>
>>>> Not yet.
>>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
>>>> with the SOC name. This binding is just used for describing the compatible string now.
>>>> When more functions on hi3519 SOC are added later, the specific driver will be also
>>>> needed.
>>>
>>> Save this binding until it has more functionality. We here "I'll add
>>> to this later" all too often.
>>>
>>
>> In the hi3519.dtsi file, there is a system-controller device node described like below:
>> sysctrl: system-controller@12010000 {
>> compatible = "hisilicon,hi3519-sysctrl", "syscon";
>> reg = <0x12010000 0x1000>;
>> };
>> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
>> compatible string?
>
> Where is this compatible string _used_?
>
>> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
>> Could you give some suggestions? Thank you very much!
>
> If you're not using the compatible i.e. the device doesn't have its
> own driver yet, then there is no need to supply the binding at all, is
> there?
>
OK. Thank you.
>>>>>> So I think it's better to keep this binding.
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-12 9:28 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-12 9:28 UTC (permalink / raw)
To: Lee Jones
Cc: mturquette, sboyd, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On 2016/1/12 16:39, Lee Jones wrote:
> On Tue, 12 Jan 2016, xuejiancheng wrote:
>
>> Hello Lee,
>>
>> On 2016/1/12 15:41, Lee Jones wrote:
>>> On Tue, 12 Jan 2016, xuejiancheng wrote:
>>>
>>>>
>>>>
>>>> On 2016/1/11 16:55, Lee Jones wrote:
>>>>> On Mon, 11 Jan 2016, xuejiancheng wrote:
>>>>>> On 2016/1/11 13:48, Lee Jones wrote:
>>>>>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>>>>>>>
>>>>>>>> Add device tree bindings for Hi3519 system controller.
>>>>>>>>
>>>>>>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>>>>>>>> ---
>>>>>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>>>>>>>> 1 file changed, 14 insertions(+)
>>>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>>>
>>>>>>> I have this patch, but none of the others in the set, thus I am
>>>>>>> lacking context.
>>>>>>>
>>>>>> I can forward other patches in the set to you. Thank you.
>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..115c5be
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>>>> @@ -0,0 +1,14 @@
>>>>>>>> +* Hisilicon Hi3519 System Controller Block
>>>>>>>> +
>>>>>>>> +This bindings use the following binding:
>>>>>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +- compatible: "hisilicon,hi3519-sysctrl".
>>>>>>>> +- reg: the register region of this block
>>>>>>>> +
>>>>>>>> +Examples:
>>>>>>>> +sysctrl: system-controller@12010000 {
>>>>>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>>>>>> + reg = <0x12010000 0x1000>;
>>>>>>>> +};
>>>>>>>
>>>>>>> There is no requirement (nor want) for binding documents where the
>>>>>>> given device is simply using highly generic bindings. This just
>>>>>>> amounts to churn.
>>>>>>>
>>>>>> This block is specific for Hi3519 SOC, and may has its own driver.
>>>>>
>>>>> Does it have its own driver currently?
>>>>>
>>>> Not yet.
>>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
>>>> with the SOC name. This binding is just used for describing the compatible string now.
>>>> When more functions on hi3519 SOC are added later, the specific driver will be also
>>>> needed.
>>>
>>> Save this binding until it has more functionality. We here "I'll add
>>> to this later" all too often.
>>>
>>
>> In the hi3519.dtsi file, there is a system-controller device node described like below:
>> sysctrl: system-controller@12010000 {
>> compatible = "hisilicon,hi3519-sysctrl", "syscon";
>> reg = <0x12010000 0x1000>;
>> };
>> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
>> compatible string?
>
> Where is this compatible string _used_?
>
>> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
>> Could you give some suggestions? Thank you very much!
>
> If you're not using the compatible i.e. the device doesn't have its
> own driver yet, then there is no need to supply the binding at all, is
> there?
>
OK. Thank you.
>>>>>> So I think it's better to keep this binding.
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-12 9:28 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-12 9:28 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/12 16:39, Lee Jones wrote:
> On Tue, 12 Jan 2016, xuejiancheng wrote:
>
>> Hello Lee,
>>
>> On 2016/1/12 15:41, Lee Jones wrote:
>>> On Tue, 12 Jan 2016, xuejiancheng wrote:
>>>
>>>>
>>>>
>>>> On 2016/1/11 16:55, Lee Jones wrote:
>>>>> On Mon, 11 Jan 2016, xuejiancheng wrote:
>>>>>> On 2016/1/11 13:48, Lee Jones wrote:
>>>>>>> On Fri, 08 Jan 2016, Jiancheng Xue wrote:
>>>>>>>
>>>>>>>> Add device tree bindings for Hi3519 system controller.
>>>>>>>>
>>>>>>>> Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com>
>>>>>>>> ---
>>>>>>>> Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++++++++++++++
>>>>>>>> 1 file changed, 14 insertions(+)
>>>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>>>
>>>>>>> I have this patch, but none of the others in the set, thus I am
>>>>>>> lacking context.
>>>>>>>
>>>>>> I can forward other patches in the set to you. Thank you.
>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..115c5be
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
>>>>>>>> @@ -0,0 +1,14 @@
>>>>>>>> +* Hisilicon Hi3519 System Controller Block
>>>>>>>> +
>>>>>>>> +This bindings use the following binding:
>>>>>>>> +Documentation/devicetree/bindings/mfd/syscon.txt
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +- compatible: "hisilicon,hi3519-sysctrl".
>>>>>>>> +- reg: the register region of this block
>>>>>>>> +
>>>>>>>> +Examples:
>>>>>>>> +sysctrl: system-controller at 12010000 {
>>>>>>>> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>>>>>> + reg = <0x12010000 0x1000>;
>>>>>>>> +};
>>>>>>>
>>>>>>> There is no requirement (nor want) for binding documents where the
>>>>>>> given device is simply using highly generic bindings. This just
>>>>>>> amounts to churn.
>>>>>>>
>>>>>> This block is specific for Hi3519 SOC, and may has its own driver.
>>>>>
>>>>> Does it have its own driver currently?
>>>>>
>>>> Not yet.
>>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
>>>> with the SOC name. This binding is just used for describing the compatible string now.
>>>> When more functions on hi3519 SOC are added later, the specific driver will be also
>>>> needed.
>>>
>>> Save this binding until it has more functionality. We here "I'll add
>>> to this later" all too often.
>>>
>>
>> In the hi3519.dtsi file, there is a system-controller device node described like below:
>> sysctrl: system-controller at 12010000 {
>> compatible = "hisilicon,hi3519-sysctrl", "syscon";
>> reg = <0x12010000 0x1000>;
>> };
>> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
>> compatible string??
>
> Where is this compatible string _used_?
>
>> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
>> Could you give some suggestions? Thank you very much!
>
> If you're not using the compatible i.e. the device doesn't have its
> own driver yet, then there is no need to supply the binding at all, is
> there?
>
OK. Thank you.
>>>>>> So I think it's better to keep this binding.
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-08 2:16 ` Jiancheng Xue
@ 2016-01-12 22:12 ` Stephen Boyd
-1 siblings, 0 replies; 103+ messages in thread
From: Stephen Boyd @ 2016-01-12 22:12 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mturquette, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On 01/08, Jiancheng Xue wrote:
> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
> index e434854..b6baebf 100644
> --- a/drivers/clk/hisilicon/Kconfig
> +++ b/drivers/clk/hisilicon/Kconfig
> @@ -1,3 +1,10 @@
> +config COMMON_CLK_HI3519
> + tristate "Clock Driver for Hi3519"
It looks like this has to be bool. Otherwise it needs to be a
platform driver and the hisilicon APIs need to be exported and
lose their __init markings.
> + depends on ARCH_HISI
> + default y
> + help
> + Build the clock driver for hi3519.
> +
> config COMMON_CLK_HI6220
> bool "Hi6220 Clock Driver"
> depends on ARCH_HISI || COMPILE_TEST
> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
> new file mode 100644
> index 0000000..72d3a7b0
> --- /dev/null
> +++ b/drivers/clk/hisilicon/clk-hi3519.c
> @@ -0,0 +1,105 @@
> +
> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
> +
> +#define HI3519_NR_CLKS 128
Is this the same clock provider as the external clocks? I don't
understand why we're offsetting the clock numbering if we have
different providers. And if these are truly fixed clocks (except
for the mux) perhaps they're not even provided by this hardware
block, and are clocks that come from the board? If that's true
then I would expect them to be described in DT as fixed rate
clocks.
> +
> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
> +};
> +
> +static const char *fmc_mux_p[] __initconst = {
const char * const ?
> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
> +
> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
> +};
> +
> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
We should look into making these things const.
> + /* fmc */
> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
> + /* uart */
> + { HI3519_UART0_CLK, "clk_uart0", "24m",
> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
> + { HI3519_UART1_CLK, "clk_uart1", "24m",
> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
> + { HI3519_UART2_CLK, "clk_uart2", "24m",
> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
> + { HI3519_UART3_CLK, "clk_uart3", "24m",
> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
> + { HI3519_UART4_CLK, "clk_uart4", "24m",
> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
> +};
> +
> +static void __init hi3519_clk_init(struct device_node *np)
> +{
> + struct hisi_clock_data *clk_data;
> +
> +
> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
> + if (!clk_data)
> + return;
> +
> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
> + ARRAY_SIZE(hi3519_fixed_rate_clks),
> + clk_data);
> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
> + clk_data);
> + hisi_clk_register_gate(hi3519_gate_clks,
> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
> +
> + hisi_reset_init(np);
> +}
> +
> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
> new file mode 100644
> index 0000000..37856089
> --- /dev/null
> +++ b/drivers/clk/hisilicon/reset.h
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __HISI_RESET_H
> +#define __HISI_RESET_H
> +
> +#include <linux/of.h>
Drop this include and forward declare struct device_node instead.
> +
> +#ifdef CONFIG_RESET_CONTROLLER
> +int __init hisi_reset_init(struct device_node *np);
We don't need __init in header files.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-12 22:12 ` Stephen Boyd
0 siblings, 0 replies; 103+ messages in thread
From: Stephen Boyd @ 2016-01-12 22:12 UTC (permalink / raw)
To: linux-arm-kernel
On 01/08, Jiancheng Xue wrote:
> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
> index e434854..b6baebf 100644
> --- a/drivers/clk/hisilicon/Kconfig
> +++ b/drivers/clk/hisilicon/Kconfig
> @@ -1,3 +1,10 @@
> +config COMMON_CLK_HI3519
> + tristate "Clock Driver for Hi3519"
It looks like this has to be bool. Otherwise it needs to be a
platform driver and the hisilicon APIs need to be exported and
lose their __init markings.
> + depends on ARCH_HISI
> + default y
> + help
> + Build the clock driver for hi3519.
> +
> config COMMON_CLK_HI6220
> bool "Hi6220 Clock Driver"
> depends on ARCH_HISI || COMPILE_TEST
> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
> new file mode 100644
> index 0000000..72d3a7b0
> --- /dev/null
> +++ b/drivers/clk/hisilicon/clk-hi3519.c
> @@ -0,0 +1,105 @@
> +
> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
> +
> +#define HI3519_NR_CLKS 128
Is this the same clock provider as the external clocks? I don't
understand why we're offsetting the clock numbering if we have
different providers. And if these are truly fixed clocks (except
for the mux) perhaps they're not even provided by this hardware
block, and are clocks that come from the board? If that's true
then I would expect them to be described in DT as fixed rate
clocks.
> +
> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
> +};
> +
> +static const char *fmc_mux_p[] __initconst = {
const char * const ?
> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
> +
> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
> +};
> +
> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
We should look into making these things const.
> + /* fmc */
> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
> + /* uart */
> + { HI3519_UART0_CLK, "clk_uart0", "24m",
> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
> + { HI3519_UART1_CLK, "clk_uart1", "24m",
> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
> + { HI3519_UART2_CLK, "clk_uart2", "24m",
> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
> + { HI3519_UART3_CLK, "clk_uart3", "24m",
> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
> + { HI3519_UART4_CLK, "clk_uart4", "24m",
> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
> +};
> +
> +static void __init hi3519_clk_init(struct device_node *np)
> +{
> + struct hisi_clock_data *clk_data;
> +
> +
> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
> + if (!clk_data)
> + return;
> +
> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
> + ARRAY_SIZE(hi3519_fixed_rate_clks),
> + clk_data);
> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
> + clk_data);
> + hisi_clk_register_gate(hi3519_gate_clks,
> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
> +
> + hisi_reset_init(np);
> +}
> +
> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
> new file mode 100644
> index 0000000..37856089
> --- /dev/null
> +++ b/drivers/clk/hisilicon/reset.h
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __HISI_RESET_H
> +#define __HISI_RESET_H
> +
> +#include <linux/of.h>
Drop this include and forward declare struct device_node instead.
> +
> +#ifdef CONFIG_RESET_CONTROLLER
> +int __init hisi_reset_init(struct device_node *np);
We don't need __init in header files.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-12 9:28 ` xuejiancheng
@ 2016-01-12 22:51 ` Arnd Bergmann
-1 siblings, 0 replies; 103+ messages in thread
From: Arnd Bergmann @ 2016-01-12 22:51 UTC (permalink / raw)
To: xuejiancheng
Cc: Lee Jones, mturquette, sboyd, p.zabel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, khilman, olof,
xuwei5, haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote:
> >>>>>
> >>>> Not yet.
> >>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
> >>>> with the SOC name. This binding is just used for describing the compatible string now.
> >>>> When more functions on hi3519 SOC are added later, the specific driver will be also
> >>>> needed.
> >>>
> >>> Save this binding until it has more functionality. We here "I'll add
> >>> to this later" all too often.
> >>>
> >>
> >> In the hi3519.dtsi file, there is a system-controller device node described like below:
> >> sysctrl: system-controller@12010000 {
> >> compatible = "hisilicon,hi3519-sysctrl", "syscon";
> >> reg = <0x12010000 0x1000>;
> >> };
> >> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
> >> compatible string?
> >
> > Where is this compatible string _used_?
> >
> >> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
> >> Could you give some suggestions? Thank you very much!
> >
> > If you're not using the compatible i.e. the device doesn't have its
> > own driver yet, then there is no need to supply the binding at all, is
> > there?
> >
>
> OK. Thank you.
>
Sorry for stepping in late here. I still think that every syscon device should
come with a specific compatible string, so we have the option of creating a
driver later on, and I'd like to see a binding document that lists those strings
(which I believe exists here).
It's really hard to add compatible strings later on, anything else we can
work around by keying off that string and adding a workaround in the kernel.
Arnd
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-12 22:51 ` Arnd Bergmann
0 siblings, 0 replies; 103+ messages in thread
From: Arnd Bergmann @ 2016-01-12 22:51 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote:
> >>>>>
> >>>> Not yet.
> >>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
> >>>> with the SOC name. This binding is just used for describing the compatible string now.
> >>>> When more functions on hi3519 SOC are added later, the specific driver will be also
> >>>> needed.
> >>>
> >>> Save this binding until it has more functionality. We here "I'll add
> >>> to this later" all too often.
> >>>
> >>
> >> In the hi3519.dtsi file, there is a system-controller device node described like below:
> >> sysctrl: system-controller at 12010000 {
> >> compatible = "hisilicon,hi3519-sysctrl", "syscon";
> >> reg = <0x12010000 0x1000>;
> >> };
> >> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
> >> compatible string??
> >
> > Where is this compatible string _used_?
> >
> >> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
> >> Could you give some suggestions? Thank you very much!
> >
> > If you're not using the compatible i.e. the device doesn't have its
> > own driver yet, then there is no need to supply the binding at all, is
> > there?
> >
>
> OK. Thank you.
>
Sorry for stepping in late here. I still think that every syscon device should
come with a specific compatible string, so we have the option of creating a
driver later on, and I'd like to see a binding document that lists those strings
(which I believe exists here).
It's really hard to add compatible strings later on, anything else we can
work around by keying off that string and adding a workaround in the kernel.
Arnd
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-12 22:12 ` Stephen Boyd
(?)
@ 2016-01-13 3:03 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-13 3:03 UTC (permalink / raw)
To: Stephen Boyd
Cc: mturquette, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hi Stephen,
Thank you very much for your reply.
On 2016/1/13 6:12, Stephen Boyd wrote:
> On 01/08, Jiancheng Xue wrote:
>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>> index e434854..b6baebf 100644
>> --- a/drivers/clk/hisilicon/Kconfig
>> +++ b/drivers/clk/hisilicon/Kconfig
>> @@ -1,3 +1,10 @@
>> +config COMMON_CLK_HI3519
>> + tristate "Clock Driver for Hi3519"
>
> It looks like this has to be bool. Otherwise it needs to be a
> platform driver and the hisilicon APIs need to be exported and
> lose their __init markings.
>
Yes,it's a problem. I will fix it in next version. Thank you.
>> + depends on ARCH_HISI
>> + default y
>> + help
>> + Build the clock driver for hi3519.
>> +
>> config COMMON_CLK_HI6220
>> bool "Hi6220 Clock Driver"
>> depends on ARCH_HISI || COMPILE_TEST
>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>> new file mode 100644
>> index 0000000..72d3a7b0
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>> @@ -0,0 +1,105 @@
>> +
>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>> +
>> +#define HI3519_NR_CLKS 128
>
> Is this the same clock provider as the external clocks? I don't
> understand why we're offsetting the clock numbering if we have
> different providers. And if these are truly fixed clocks (except
> for the mux) perhaps they're not even provided by this hardware
> block, and are clocks that come from the board? If that's true
> then I would expect them to be described in DT as fixed rate
> clocks.
>
External clocks mentioned here are used directly as work clocks of other modules.
Clocks defined in this file (internal clocks) are used as parents of external
clocks. Internal clocks won't be referred by dts files and are just used in this driver.
So they are moved here from the header file.
External clocks and internal clocks are all generated by this CRG block. The input clock
of the CRG block is always connected to a crystal oscillator on the board. So only one
clock provider is defined here.
Some clocks generated by CRG won't change their rate during the system running. These clocks
are treated as fixed clocks here.
>> +
>> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
>> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
>> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
>> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
>> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
>> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
>> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
>> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
>> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
>> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
>> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
>> +};
>> +
>> +static const char *fmc_mux_p[] __initconst = {
>
> const char * const ?
>
OK.
>> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
>> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
>> +
>> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
>> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
>> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
>> +};
>> +
>> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
>
> We should look into making these things const.
>
OK. I'll add this in next version.
>> + /* fmc */
>> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
>> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
>> + /* uart */
>> + { HI3519_UART0_CLK, "clk_uart0", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
>> + { HI3519_UART1_CLK, "clk_uart1", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
>> + { HI3519_UART2_CLK, "clk_uart2", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
>> + { HI3519_UART3_CLK, "clk_uart3", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
>> + { HI3519_UART4_CLK, "clk_uart4", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
>> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
>> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
>> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
>> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
>> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
>> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
>> +};
>> +
>> +static void __init hi3519_clk_init(struct device_node *np)
>> +{
>> + struct hisi_clock_data *clk_data;
>> +
>> +
>> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
>> + if (!clk_data)
>> + return;
>> +
>> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
>> + ARRAY_SIZE(hi3519_fixed_rate_clks),
>> + clk_data);
>> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
>> + clk_data);
>> + hisi_clk_register_gate(hi3519_gate_clks,
>> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
>> +
>> + hisi_reset_init(np);
>> +}
>> +
>> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
>> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
>> new file mode 100644
>> index 0000000..37856089
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/reset.h
>> @@ -0,0 +1,32 @@
>> +/*
>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __HISI_RESET_H
>> +#define __HISI_RESET_H
>> +
>> +#include <linux/of.h>
>
> Drop this include and forward declare struct device_node instead.
>
OK.
>> +
>> +#ifdef CONFIG_RESET_CONTROLLER
>> +int __init hisi_reset_init(struct device_node *np);
>
> We don't need __init in header files.
>
OK. I'll remove it. Thank you.
Jiancheng
.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-13 3:03 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-13 3:03 UTC (permalink / raw)
To: Stephen Boyd
Cc: mturquette, p.zabel, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, linux, khilman, arnd, olof, xuwei5,
haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hi Stephen,
Thank you very much for your reply.
On 2016/1/13 6:12, Stephen Boyd wrote:
> On 01/08, Jiancheng Xue wrote:
>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>> index e434854..b6baebf 100644
>> --- a/drivers/clk/hisilicon/Kconfig
>> +++ b/drivers/clk/hisilicon/Kconfig
>> @@ -1,3 +1,10 @@
>> +config COMMON_CLK_HI3519
>> + tristate "Clock Driver for Hi3519"
>
> It looks like this has to be bool. Otherwise it needs to be a
> platform driver and the hisilicon APIs need to be exported and
> lose their __init markings.
>
Yes,it's a problem. I will fix it in next version. Thank you.
>> + depends on ARCH_HISI
>> + default y
>> + help
>> + Build the clock driver for hi3519.
>> +
>> config COMMON_CLK_HI6220
>> bool "Hi6220 Clock Driver"
>> depends on ARCH_HISI || COMPILE_TEST
>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>> new file mode 100644
>> index 0000000..72d3a7b0
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>> @@ -0,0 +1,105 @@
>> +
>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>> +
>> +#define HI3519_NR_CLKS 128
>
> Is this the same clock provider as the external clocks? I don't
> understand why we're offsetting the clock numbering if we have
> different providers. And if these are truly fixed clocks (except
> for the mux) perhaps they're not even provided by this hardware
> block, and are clocks that come from the board? If that's true
> then I would expect them to be described in DT as fixed rate
> clocks.
>
External clocks mentioned here are used directly as work clocks of other modules.
Clocks defined in this file (internal clocks) are used as parents of external
clocks. Internal clocks won't be referred by dts files and are just used in this driver.
So they are moved here from the header file.
External clocks and internal clocks are all generated by this CRG block. The input clock
of the CRG block is always connected to a crystal oscillator on the board. So only one
clock provider is defined here.
Some clocks generated by CRG won't change their rate during the system running. These clocks
are treated as fixed clocks here.
>> +
>> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
>> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
>> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
>> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
>> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
>> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
>> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
>> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
>> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
>> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
>> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
>> +};
>> +
>> +static const char *fmc_mux_p[] __initconst = {
>
> const char * const ?
>
OK.
>> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
>> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
>> +
>> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
>> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
>> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
>> +};
>> +
>> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
>
> We should look into making these things const.
>
OK. I'll add this in next version.
>> + /* fmc */
>> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
>> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
>> + /* uart */
>> + { HI3519_UART0_CLK, "clk_uart0", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
>> + { HI3519_UART1_CLK, "clk_uart1", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
>> + { HI3519_UART2_CLK, "clk_uart2", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
>> + { HI3519_UART3_CLK, "clk_uart3", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
>> + { HI3519_UART4_CLK, "clk_uart4", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
>> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
>> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
>> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
>> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
>> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
>> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
>> +};
>> +
>> +static void __init hi3519_clk_init(struct device_node *np)
>> +{
>> + struct hisi_clock_data *clk_data;
>> +
>> +
>> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
>> + if (!clk_data)
>> + return;
>> +
>> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
>> + ARRAY_SIZE(hi3519_fixed_rate_clks),
>> + clk_data);
>> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
>> + clk_data);
>> + hisi_clk_register_gate(hi3519_gate_clks,
>> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
>> +
>> + hisi_reset_init(np);
>> +}
>> +
>> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
>> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
>> new file mode 100644
>> index 0000000..37856089
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/reset.h
>> @@ -0,0 +1,32 @@
>> +/*
>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __HISI_RESET_H
>> +#define __HISI_RESET_H
>> +
>> +#include <linux/of.h>
>
> Drop this include and forward declare struct device_node instead.
>
OK.
>> +
>> +#ifdef CONFIG_RESET_CONTROLLER
>> +int __init hisi_reset_init(struct device_node *np);
>
> We don't need __init in header files.
>
OK. I'll remove it. Thank you.
Jiancheng
.
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-13 3:03 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-13 3:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi Stephen,
Thank you very much for your reply.
On 2016/1/13 6:12, Stephen Boyd wrote:
> On 01/08, Jiancheng Xue wrote:
>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>> index e434854..b6baebf 100644
>> --- a/drivers/clk/hisilicon/Kconfig
>> +++ b/drivers/clk/hisilicon/Kconfig
>> @@ -1,3 +1,10 @@
>> +config COMMON_CLK_HI3519
>> + tristate "Clock Driver for Hi3519"
>
> It looks like this has to be bool. Otherwise it needs to be a
> platform driver and the hisilicon APIs need to be exported and
> lose their __init markings.
>
Yes,it's a problem. I will fix it in next version. Thank you.
>> + depends on ARCH_HISI
>> + default y
>> + help
>> + Build the clock driver for hi3519.
>> +
>> config COMMON_CLK_HI6220
>> bool "Hi6220 Clock Driver"
>> depends on ARCH_HISI || COMPILE_TEST
>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>> new file mode 100644
>> index 0000000..72d3a7b0
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>> @@ -0,0 +1,105 @@
>> +
>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>> +
>> +#define HI3519_NR_CLKS 128
>
> Is this the same clock provider as the external clocks? I don't
> understand why we're offsetting the clock numbering if we have
> different providers. And if these are truly fixed clocks (except
> for the mux) perhaps they're not even provided by this hardware
> block, and are clocks that come from the board? If that's true
> then I would expect them to be described in DT as fixed rate
> clocks.
>
External clocks mentioned here are used directly as work clocks of other modules.
Clocks defined in this file (internal clocks) are used as parents of external
clocks. Internal clocks won't be referred by dts files and are just used in this driver.
So they are moved here from the header file.
External clocks and internal clocks are all generated by this CRG block. The input clock
of the CRG block is always connected to a crystal oscillator on the board. So only one
clock provider is defined here.
Some clocks generated by CRG won't change their rate during the system running. These clocks
are treated as fixed clocks here.
>> +
>> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
>> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
>> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
>> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
>> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
>> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
>> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
>> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
>> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
>> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
>> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
>> +};
>> +
>> +static const char *fmc_mux_p[] __initconst = {
>
> const char * const ?
>
OK.
>> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
>> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
>> +
>> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
>> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
>> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
>> +};
>> +
>> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
>
> We should look into making these things const.
>
OK. I'll add this in next version.
>> + /* fmc */
>> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
>> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
>> + /* uart */
>> + { HI3519_UART0_CLK, "clk_uart0", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
>> + { HI3519_UART1_CLK, "clk_uart1", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
>> + { HI3519_UART2_CLK, "clk_uart2", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
>> + { HI3519_UART3_CLK, "clk_uart3", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
>> + { HI3519_UART4_CLK, "clk_uart4", "24m",
>> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
>> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
>> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
>> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
>> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
>> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
>> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
>> +};
>> +
>> +static void __init hi3519_clk_init(struct device_node *np)
>> +{
>> + struct hisi_clock_data *clk_data;
>> +
>> +
>> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
>> + if (!clk_data)
>> + return;
>> +
>> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
>> + ARRAY_SIZE(hi3519_fixed_rate_clks),
>> + clk_data);
>> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
>> + clk_data);
>> + hisi_clk_register_gate(hi3519_gate_clks,
>> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
>> +
>> + hisi_reset_init(np);
>> +}
>> +
>> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
>> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
>> new file mode 100644
>> index 0000000..37856089
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/reset.h
>> @@ -0,0 +1,32 @@
>> +/*
>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __HISI_RESET_H
>> +#define __HISI_RESET_H
>> +
>> +#include <linux/of.h>
>
> Drop this include and forward declare struct device_node instead.
>
OK.
>> +
>> +#ifdef CONFIG_RESET_CONTROLLER
>> +int __init hisi_reset_init(struct device_node *np);
>
> We don't need __init in header files.
>
OK. I'll remove it. Thank you.
Jiancheng
.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-12 22:51 ` Arnd Bergmann
(?)
@ 2016-01-13 9:08 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-13 9:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lee Jones, mturquette, sboyd, p.zabel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, khilman, olof,
xuwei5, haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hi Arnd,
On 2016/1/13 6:51, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote:
>>>>>>>
>>>>>> Not yet.
>>>>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
>>>>>> with the SOC name. This binding is just used for describing the compatible string now.
>>>>>> When more functions on hi3519 SOC are added later, the specific driver will be also
>>>>>> needed.
>>>>>
>>>>> Save this binding until it has more functionality. We here "I'll add
>>>>> to this later" all too often.
>>>>>
>>>>
>>>> In the hi3519.dtsi file, there is a system-controller device node described like below:
>>>> sysctrl: system-controller@12010000 {
>>>> compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>> reg = <0x12010000 0x1000>;
>>>> };
>>>> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
>>>> compatible string?
>>>
>>> Where is this compatible string _used_?
>>>
>>>> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
>>>> Could you give some suggestions? Thank you very much!
>>>
>>> If you're not using the compatible i.e. the device doesn't have its
>>> own driver yet, then there is no need to supply the binding at all, is
>>> there?
>>>
>>
>> OK. Thank you.
>>
>
> Sorry for stepping in late here. I still think that every syscon device should
> come with a specific compatible string, so we have the option of creating a
> driver later on, and I'd like to see a binding document that lists those strings
> (which I believe exists here).
>
> It's really hard to add compatible strings later on, anything else we can
> work around by keying off that string and adding a workaround in the kernel.
>
Is it OK if I put this binding document into the directory "Documentation/devicetree/bindings/arm/hisilicon"?
Thank you.
> Arnd
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-13 9:08 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-13 9:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lee Jones, mturquette, sboyd, p.zabel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, khilman, olof,
xuwei5, haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
Hi Arnd,
On 2016/1/13 6:51, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote:
>>>>>>>
>>>>>> Not yet.
>>>>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
>>>>>> with the SOC name. This binding is just used for describing the compatible string now.
>>>>>> When more functions on hi3519 SOC are added later, the specific driver will be also
>>>>>> needed.
>>>>>
>>>>> Save this binding until it has more functionality. We here "I'll add
>>>>> to this later" all too often.
>>>>>
>>>>
>>>> In the hi3519.dtsi file, there is a system-controller device node described like below:
>>>> sysctrl: system-controller@12010000 {
>>>> compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>> reg = <0x12010000 0x1000>;
>>>> };
>>>> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
>>>> compatible string?
>>>
>>> Where is this compatible string _used_?
>>>
>>>> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
>>>> Could you give some suggestions? Thank you very much!
>>>
>>> If you're not using the compatible i.e. the device doesn't have its
>>> own driver yet, then there is no need to supply the binding at all, is
>>> there?
>>>
>>
>> OK. Thank you.
>>
>
> Sorry for stepping in late here. I still think that every syscon device should
> come with a specific compatible string, so we have the option of creating a
> driver later on, and I'd like to see a binding document that lists those strings
> (which I believe exists here).
>
> It's really hard to add compatible strings later on, anything else we can
> work around by keying off that string and adding a workaround in the kernel.
>
Is it OK if I put this binding document into the directory "Documentation/devicetree/bindings/arm/hisilicon"?
Thank you.
> Arnd
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-13 9:08 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-13 9:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
On 2016/1/13 6:51, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote:
>>>>>>>
>>>>>> Not yet.
>>>>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
>>>>>> with the SOC name. This binding is just used for describing the compatible string now.
>>>>>> When more functions on hi3519 SOC are added later, the specific driver will be also
>>>>>> needed.
>>>>>
>>>>> Save this binding until it has more functionality. We here "I'll add
>>>>> to this later" all too often.
>>>>>
>>>>
>>>> In the hi3519.dtsi file, there is a system-controller device node described like below:
>>>> sysctrl: system-controller at 12010000 {
>>>> compatible = "hisilicon,hi3519-sysctrl", "syscon";
>>>> reg = <0x12010000 0x1000>;
>>>> };
>>>> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
>>>> compatible string??
>>>
>>> Where is this compatible string _used_?
>>>
>>>> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
>>>> Could you give some suggestions? Thank you very much!
>>>
>>> If you're not using the compatible i.e. the device doesn't have its
>>> own driver yet, then there is no need to supply the binding at all, is
>>> there?
>>>
>>
>> OK. Thank you.
>>
>
> Sorry for stepping in late here. I still think that every syscon device should
> come with a specific compatible string, so we have the option of creating a
> driver later on, and I'd like to see a binding document that lists those strings
> (which I believe exists here).
>
> It's really hard to add compatible strings later on, anything else we can
> work around by keying off that string and adding a workaround in the kernel.
>
Is it OK if I put this binding document into the directory "Documentation/devicetree/bindings/arm/hisilicon"?
Thank you.
> Arnd
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-13 9:08 ` xuejiancheng
@ 2016-01-13 10:00 ` Arnd Bergmann
-1 siblings, 0 replies; 103+ messages in thread
From: Arnd Bergmann @ 2016-01-13 10:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: xuejiancheng, mark.rutland, suwenping, mturquette, bintian.wang,
haojian.zhuang, Lee Jones, linux-clk, linux, xuwei5,
zhangfei.gao, zhangzhenxing, devicetree, khilman, pawel.moll,
ijc+devicetree, yanhaifeng, ml.yang, robh+dt, xuejiancheng,
sboyd, linux-kernel, gaofei, p.zabel, galak, olof, yanghongwei
On Wednesday 13 January 2016 17:08:20 xuejiancheng wrote:
> >
>
> Is it OK if I put this binding document into the directory "Documentation/devicetree/bindings/arm/hisilicon"?
>
Yes, sounds good.
Arnd
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-13 10:00 ` Arnd Bergmann
0 siblings, 0 replies; 103+ messages in thread
From: Arnd Bergmann @ 2016-01-13 10:00 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 13 January 2016 17:08:20 xuejiancheng wrote:
> >
>
> Is it OK if I put this binding document into the directory "Documentation/devicetree/bindings/arm/hisilicon"?
>
Yes, sounds good.
Arnd
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-13 3:03 ` xuejiancheng
(?)
@ 2016-01-13 18:57 ` Michael Turquette
-1 siblings, 0 replies; 103+ messages in thread
From: Michael Turquette @ 2016-01-13 18:57 UTC (permalink / raw)
To: xuejiancheng, Stephen Boyd
Cc: p.zabel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, linux, khilman, arnd, olof, xuwei5, haojian.zhuang,
zhangfei.gao, bintian.wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng, yanghongwei, suwenping, ml.yang,
gaofei, zhangzhenxing, xuejiancheng
Quoting xuejiancheng (2016-01-12 19:03:01)
> Hi Stephen,
> Thank you very much for your reply.
>
> On 2016/1/13 6:12, Stephen Boyd wrote:
> > On 01/08, Jiancheng Xue wrote:
> >> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
> >> index e434854..b6baebf 100644
> >> --- a/drivers/clk/hisilicon/Kconfig
> >> +++ b/drivers/clk/hisilicon/Kconfig
> >> @@ -1,3 +1,10 @@
> >> +config COMMON_CLK_HI3519
> >> + tristate "Clock Driver for Hi3519"
> >
> > It looks like this has to be bool. Otherwise it needs to be a
> > platform driver and the hisilicon APIs need to be exported and
> > lose their __init markings.
> >
> Yes,it's a problem. I will fix it in next version. Thank you.
The best solution would be to make this clock driver a real platform
driver.
Regards,
Mike
>
> >> + depends on ARCH_HISI
> >> + default y
> >> + help
> >> + Build the clock driver for hi3519.
> >> +
> >> config COMMON_CLK_HI6220
> >> bool "Hi6220 Clock Driver"
> >> depends on ARCH_HISI || COMPILE_TEST
> >> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
> >> new file mode 100644
> >> index 0000000..72d3a7b0
> >> --- /dev/null
> >> +++ b/drivers/clk/hisilicon/clk-hi3519.c
> >> @@ -0,0 +1,105 @@
> >> +
> >> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
> >> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
> >> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
> >> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
> >> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
> >> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
> >> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
> >> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
> >> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
> >> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
> >> +
> >> +#define HI3519_NR_CLKS 128
> >
> > Is this the same clock provider as the external clocks? I don't
> > understand why we're offsetting the clock numbering if we have
> > different providers. And if these are truly fixed clocks (except
> > for the mux) perhaps they're not even provided by this hardware
> > block, and are clocks that come from the board? If that's true
> > then I would expect them to be described in DT as fixed rate
> > clocks.
> >
> External clocks mentioned here are used directly as work clocks of other modules.
> Clocks defined in this file (internal clocks) are used as parents of external
> clocks. Internal clocks won't be referred by dts files and are just used in this driver.
> So they are moved here from the header file.
>
> External clocks and internal clocks are all generated by this CRG block. The input clock
> of the CRG block is always connected to a crystal oscillator on the board. So only one
> clock provider is defined here.
>
> Some clocks generated by CRG won't change their rate during the system running. These clocks
> are treated as fixed clocks here.
>
> >> +
> >> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
> >> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
> >> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
> >> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
> >> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
> >> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
> >> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
> >> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
> >> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
> >> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
> >> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
> >> +};
> >> +
> >> +static const char *fmc_mux_p[] __initconst = {
> >
> > const char * const ?
> >
>
> OK.
>
> >> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
> >> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
> >> +
> >> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
> >> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
> >> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
> >> +};
> >> +
> >> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
> >
> > We should look into making these things const.
> >
> OK. I'll add this in next version.
>
> >> + /* fmc */
> >> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
> >> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
> >> + /* uart */
> >> + { HI3519_UART0_CLK, "clk_uart0", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
> >> + { HI3519_UART1_CLK, "clk_uart1", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
> >> + { HI3519_UART2_CLK, "clk_uart2", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
> >> + { HI3519_UART3_CLK, "clk_uart3", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
> >> + { HI3519_UART4_CLK, "clk_uart4", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
> >> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
> >> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
> >> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
> >> +};
> >> +
> >> +static void __init hi3519_clk_init(struct device_node *np)
> >> +{
> >> + struct hisi_clock_data *clk_data;
> >> +
> >> +
> >> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
> >> + if (!clk_data)
> >> + return;
> >> +
> >> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
> >> + ARRAY_SIZE(hi3519_fixed_rate_clks),
> >> + clk_data);
> >> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
> >> + clk_data);
> >> + hisi_clk_register_gate(hi3519_gate_clks,
> >> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
> >> +
> >> + hisi_reset_init(np);
> >> +}
> >> +
> >> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
> >> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
> >> new file mode 100644
> >> index 0000000..37856089
> >> --- /dev/null
> >> +++ b/drivers/clk/hisilicon/reset.h
> >> @@ -0,0 +1,32 @@
> >> +/*
> >> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> >> + */
> >> +
> >> +#ifndef __HISI_RESET_H
> >> +#define __HISI_RESET_H
> >> +
> >> +#include <linux/of.h>
> >
> > Drop this include and forward declare struct device_node instead.
> >
>
> OK.
>
> >> +
> >> +#ifdef CONFIG_RESET_CONTROLLER
> >> +int __init hisi_reset_init(struct device_node *np);
> >
> > We don't need __init in header files.
> >
> OK. I'll remove it. Thank you.
>
> Jiancheng
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-13 18:57 ` Michael Turquette
0 siblings, 0 replies; 103+ messages in thread
From: Michael Turquette @ 2016-01-13 18:57 UTC (permalink / raw)
To: xuejiancheng, Stephen Boyd
Cc: p.zabel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, linux, khilman, arnd, olof, xuwei5, haojian.zhuang,
zhangfei.gao, bintian.wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng, yanghongwei, suwenping, ml.yang,
gaofei, zhangzhenxing, xuejiancheng
Quoting xuejiancheng (2016-01-12 19:03:01)
> Hi Stephen,
> Thank you very much for your reply.
> =
> On 2016/1/13 6:12, Stephen Boyd wrote:
> > On 01/08, Jiancheng Xue wrote:
> >> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kco=
nfig
> >> index e434854..b6baebf 100644
> >> --- a/drivers/clk/hisilicon/Kconfig
> >> +++ b/drivers/clk/hisilicon/Kconfig
> >> @@ -1,3 +1,10 @@
> >> +config COMMON_CLK_HI3519
> >> + tristate "Clock Driver for Hi3519"
> > =
> > It looks like this has to be bool. Otherwise it needs to be a
> > platform driver and the hisilicon APIs need to be exported and
> > lose their __init markings.
> > =
> Yes,it's a problem. I will fix it in next version. Thank you.
The best solution would be to make this clock driver a real platform
driver.
Regards,
Mike
> =
> >> + depends on ARCH_HISI
> >> + default y
> >> + help
> >> + Build the clock driver for hi3519.
> >> +
> >> config COMMON_CLK_HI6220
> >> bool "Hi6220 Clock Driver"
> >> depends on ARCH_HISI || COMPILE_TEST
> >> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilico=
n/clk-hi3519.c
> >> new file mode 100644
> >> index 0000000..72d3a7b0
> >> --- /dev/null
> >> +++ b/drivers/clk/hisilicon/clk-hi3519.c
> >> @@ -0,0 +1,105 @@
> >> +
> >> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
> >> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
> >> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
> >> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
> >> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
> >> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
> >> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
> >> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
> >> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
> >> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
> >> +
> >> +#define HI3519_NR_CLKS 128
> > =
> > Is this the same clock provider as the external clocks? I don't
> > understand why we're offsetting the clock numbering if we have
> > different providers. And if these are truly fixed clocks (except
> > for the mux) perhaps they're not even provided by this hardware
> > block, and are clocks that come from the board? If that's true
> > then I would expect them to be described in DT as fixed rate
> > clocks.
> > =
> External clocks mentioned here are used directly as work clocks of other =
modules.
> Clocks defined in this file (internal clocks) are used as parents of exte=
rnal
> clocks. Internal clocks won't be referred by dts files and are just used =
in this driver.
> So they are moved here from the header file.
> =
> External clocks and internal clocks are all generated by this CRG block. =
The input clock
> of the CRG block is always connected to a crystal oscillator on the board=
. So only one
> clock provider is defined here.
> =
> Some clocks generated by CRG won't change their rate during the system ru=
nning. These clocks
> are treated as fixed clocks here.
> =
> >> +
> >> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initda=
ta =3D {
> >> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
> >> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
> >> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
> >> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
> >> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
> >> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
> >> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
> >> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
> >> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
> >> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
> >> +};
> >> +
> >> +static const char *fmc_mux_p[] __initconst =3D {
> > =
> > const char * const ?
> > =
> =
> OK.
> =
> >> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "40=
0m", };
> >> +static u32 fmc_mux_table[] =3D {0, 1, 2, 3, 4, 5, 6, 7};
> >> +
> >> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata =3D {
> >> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
> >> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
> >> +};
> >> +
> >> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata =3D {
> > =
> > We should look into making these things const.
> > =
> OK. I'll add this in next version.
> =
> >> + /* fmc */
> >> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
> >> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
> >> + /* uart */
> >> + { HI3519_UART0_CLK, "clk_uart0", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
> >> + { HI3519_UART1_CLK, "clk_uart1", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
> >> + { HI3519_UART2_CLK, "clk_uart2", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
> >> + { HI3519_UART3_CLK, "clk_uart3", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
> >> + { HI3519_UART4_CLK, "clk_uart4", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
> >> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
> >> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
> >> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
> >> +};
> >> +
> >> +static void __init hi3519_clk_init(struct device_node *np)
> >> +{
> >> + struct hisi_clock_data *clk_data;
> >> +
> >> +
> >> + clk_data =3D hisi_clk_init(np, HI3519_NR_CLKS);
> >> + if (!clk_data)
> >> + return;
> >> +
> >> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
> >> + ARRAY_SIZE(hi3519_fixed_rate_clks),
> >> + clk_data);
> >> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks=
),
> >> + clk_data);
> >> + hisi_clk_register_gate(hi3519_gate_clks,
> >> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
> >> +
> >> + hisi_reset_init(np);
> >> +}
> >> +
> >> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
> >> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/res=
et.h
> >> new file mode 100644
> >> index 0000000..37856089
> >> --- /dev/null
> >> +++ b/drivers/clk/hisilicon/reset.h
> >> @@ -0,0 +1,32 @@
> >> +/*
> >> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modi=
fy
> >> + * it under the terms of the GNU General Public License as published =
by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program. If not, see <http://www.gnu.org/licenses/=
>.
> >> + */
> >> +
> >> +#ifndef __HISI_RESET_H
> >> +#define __HISI_RESET_H
> >> +
> >> +#include <linux/of.h>
> > =
> > Drop this include and forward declare struct device_node instead.
> > =
> =
> OK.
> =
> >> +
> >> +#ifdef CONFIG_RESET_CONTROLLER
> >> +int __init hisi_reset_init(struct device_node *np);
> > =
> > We don't need __init in header files.
> > =
> OK. I'll remove it. Thank you.
> =
> Jiancheng
> .
>=20
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-13 18:57 ` Michael Turquette
0 siblings, 0 replies; 103+ messages in thread
From: Michael Turquette @ 2016-01-13 18:57 UTC (permalink / raw)
To: linux-arm-kernel
Quoting xuejiancheng (2016-01-12 19:03:01)
> Hi Stephen,
> Thank you very much for your reply.
>
> On 2016/1/13 6:12, Stephen Boyd wrote:
> > On 01/08, Jiancheng Xue wrote:
> >> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
> >> index e434854..b6baebf 100644
> >> --- a/drivers/clk/hisilicon/Kconfig
> >> +++ b/drivers/clk/hisilicon/Kconfig
> >> @@ -1,3 +1,10 @@
> >> +config COMMON_CLK_HI3519
> >> + tristate "Clock Driver for Hi3519"
> >
> > It looks like this has to be bool. Otherwise it needs to be a
> > platform driver and the hisilicon APIs need to be exported and
> > lose their __init markings.
> >
> Yes,it's a problem. I will fix it in next version. Thank you.
The best solution would be to make this clock driver a real platform
driver.
Regards,
Mike
>
> >> + depends on ARCH_HISI
> >> + default y
> >> + help
> >> + Build the clock driver for hi3519.
> >> +
> >> config COMMON_CLK_HI6220
> >> bool "Hi6220 Clock Driver"
> >> depends on ARCH_HISI || COMPILE_TEST
> >> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
> >> new file mode 100644
> >> index 0000000..72d3a7b0
> >> --- /dev/null
> >> +++ b/drivers/clk/hisilicon/clk-hi3519.c
> >> @@ -0,0 +1,105 @@
> >> +
> >> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
> >> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
> >> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
> >> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
> >> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
> >> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
> >> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
> >> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
> >> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
> >> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
> >> +
> >> +#define HI3519_NR_CLKS 128
> >
> > Is this the same clock provider as the external clocks? I don't
> > understand why we're offsetting the clock numbering if we have
> > different providers. And if these are truly fixed clocks (except
> > for the mux) perhaps they're not even provided by this hardware
> > block, and are clocks that come from the board? If that's true
> > then I would expect them to be described in DT as fixed rate
> > clocks.
> >
> External clocks mentioned here are used directly as work clocks of other modules.
> Clocks defined in this file (internal clocks) are used as parents of external
> clocks. Internal clocks won't be referred by dts files and are just used in this driver.
> So they are moved here from the header file.
>
> External clocks and internal clocks are all generated by this CRG block. The input clock
> of the CRG block is always connected to a crystal oscillator on the board. So only one
> clock provider is defined here.
>
> Some clocks generated by CRG won't change their rate during the system running. These clocks
> are treated as fixed clocks here.
>
> >> +
> >> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
> >> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
> >> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
> >> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
> >> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
> >> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
> >> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
> >> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
> >> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
> >> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
> >> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
> >> +};
> >> +
> >> +static const char *fmc_mux_p[] __initconst = {
> >
> > const char * const ?
> >
>
> OK.
>
> >> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
> >> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
> >> +
> >> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
> >> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
> >> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
> >> +};
> >> +
> >> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
> >
> > We should look into making these things const.
> >
> OK. I'll add this in next version.
>
> >> + /* fmc */
> >> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
> >> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
> >> + /* uart */
> >> + { HI3519_UART0_CLK, "clk_uart0", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
> >> + { HI3519_UART1_CLK, "clk_uart1", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
> >> + { HI3519_UART2_CLK, "clk_uart2", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
> >> + { HI3519_UART3_CLK, "clk_uart3", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
> >> + { HI3519_UART4_CLK, "clk_uart4", "24m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
> >> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
> >> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
> >> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
> >> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
> >> +};
> >> +
> >> +static void __init hi3519_clk_init(struct device_node *np)
> >> +{
> >> + struct hisi_clock_data *clk_data;
> >> +
> >> +
> >> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
> >> + if (!clk_data)
> >> + return;
> >> +
> >> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
> >> + ARRAY_SIZE(hi3519_fixed_rate_clks),
> >> + clk_data);
> >> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
> >> + clk_data);
> >> + hisi_clk_register_gate(hi3519_gate_clks,
> >> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
> >> +
> >> + hisi_reset_init(np);
> >> +}
> >> +
> >> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
> >> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
> >> new file mode 100644
> >> index 0000000..37856089
> >> --- /dev/null
> >> +++ b/drivers/clk/hisilicon/reset.h
> >> @@ -0,0 +1,32 @@
> >> +/*
> >> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> >> + */
> >> +
> >> +#ifndef __HISI_RESET_H
> >> +#define __HISI_RESET_H
> >> +
> >> +#include <linux/of.h>
> >
> > Drop this include and forward declare struct device_node instead.
> >
>
> OK.
>
> >> +
> >> +#ifdef CONFIG_RESET_CONTROLLER
> >> +int __init hisi_reset_init(struct device_node *np);
> >
> > We don't need __init in header files.
> >
> OK. I'll remove it. Thank you.
>
> Jiancheng
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-13 18:57 ` Michael Turquette
(?)
@ 2016-01-14 13:16 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-14 13:16 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: p.zabel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, linux, khilman, arnd, olof, xuwei5, haojian.zhuang,
zhangfei.gao, bintian.wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng, yanghongwei, suwenping, ml.yang,
gaofei, zhangzhenxing, xuejiancheng
Hi Mike,
On 2016/1/14 2:57, Michael Turquette wrote:
> Quoting xuejiancheng (2016-01-12 19:03:01)
>> Hi Stephen,
>> Thank you very much for your reply.
>>
>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>> On 01/08, Jiancheng Xue wrote:
>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>> index e434854..b6baebf 100644
>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>> @@ -1,3 +1,10 @@
>>>> +config COMMON_CLK_HI3519
>>>> + tristate "Clock Driver for Hi3519"
>>>
>>> It looks like this has to be bool. Otherwise it needs to be a
>>> platform driver and the hisilicon APIs need to be exported and
>>> lose their __init markings.
>>>
>> Yes,it's a problem. I will fix it in next version. Thank you.
>
> The best solution would be to make this clock driver a real platform
> driver.
>
Now the work clock of the clocksource timer-sp804 is provided by this driver. So
it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
as a fixed-clock provider, this driver can be implemented as a platform driver.
Then the crg device must be registered before other clock consumer devices.Accordingly
the crg device node must be written above all other clock consumer devices node in dts files.
I think it is also a dependence.
Can you help me understand why it is better to make this driver a platform driver?
Thank you very much!
> Regards,
> Mike
>
>>
>>>> + depends on ARCH_HISI
>>>> + default y
>>>> + help
>>>> + Build the clock driver for hi3519.
>>>> +
>>>> config COMMON_CLK_HI6220
>>>> bool "Hi6220 Clock Driver"
>>>> depends on ARCH_HISI || COMPILE_TEST
>>>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>>>> new file mode 100644
>>>> index 0000000..72d3a7b0
>>>> --- /dev/null
>>>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>>>> @@ -0,0 +1,105 @@
>>>> +
>>>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>>>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>>>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>>>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>>>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>>>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>>>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>>>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>>>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>>>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>>>> +
>>>> +#define HI3519_NR_CLKS 128
>>>
>>> Is this the same clock provider as the external clocks? I don't
>>> understand why we're offsetting the clock numbering if we have
>>> different providers. And if these are truly fixed clocks (except
>>> for the mux) perhaps they're not even provided by this hardware
>>> block, and are clocks that come from the board? If that's true
>>> then I would expect them to be described in DT as fixed rate
>>> clocks.
>>>
>> External clocks mentioned here are used directly as work clocks of other modules.
>> Clocks defined in this file (internal clocks) are used as parents of external
>> clocks. Internal clocks won't be referred by dts files and are just used in this driver.
>> So they are moved here from the header file.
>>
>> External clocks and internal clocks are all generated by this CRG block. The input clock
>> of the CRG block is always connected to a crystal oscillator on the board. So only one
>> clock provider is defined here.
>>
>> Some clocks generated by CRG won't change their rate during the system running. These clocks
>> are treated as fixed clocks here.
>>
>>>> +
>>>> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
>>>> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
>>>> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
>>>> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
>>>> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
>>>> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
>>>> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
>>>> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
>>>> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
>>>> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
>>>> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
>>>> +};
>>>> +
>>>> +static const char *fmc_mux_p[] __initconst = {
>>>
>>> const char * const ?
>>>
>>
>> OK.
>>
>>>> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
>>>> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
>>>> +
>>>> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
>>>> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
>>>> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
>>>> +};
>>>> +
>>>> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
>>>
>>> We should look into making these things const.
>>>
>> OK. I'll add this in next version.
>>
>>>> + /* fmc */
>>>> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
>>>> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
>>>> + /* uart */
>>>> + { HI3519_UART0_CLK, "clk_uart0", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
>>>> + { HI3519_UART1_CLK, "clk_uart1", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
>>>> + { HI3519_UART2_CLK, "clk_uart2", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
>>>> + { HI3519_UART3_CLK, "clk_uart3", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
>>>> + { HI3519_UART4_CLK, "clk_uart4", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
>>>> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
>>>> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
>>>> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
>>>> +};
>>>> +
>>>> +static void __init hi3519_clk_init(struct device_node *np)
>>>> +{
>>>> + struct hisi_clock_data *clk_data;
>>>> +
>>>> +
>>>> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
>>>> + if (!clk_data)
>>>> + return;
>>>> +
>>>> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
>>>> + ARRAY_SIZE(hi3519_fixed_rate_clks),
>>>> + clk_data);
>>>> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
>>>> + clk_data);
>>>> + hisi_clk_register_gate(hi3519_gate_clks,
>>>> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
>>>> +
>>>> + hisi_reset_init(np);
>>>> +}
>>>> +
>>>> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
>>>> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
>>>> new file mode 100644
>>>> index 0000000..37856089
>>>> --- /dev/null
>>>> +++ b/drivers/clk/hisilicon/reset.h
>>>> @@ -0,0 +1,32 @@
>>>> +/*
>>>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License as published by
>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>> + * (at your option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>>>> + */
>>>> +
>>>> +#ifndef __HISI_RESET_H
>>>> +#define __HISI_RESET_H
>>>> +
>>>> +#include <linux/of.h>
>>>
>>> Drop this include and forward declare struct device_node instead.
>>>
>>
>> OK.
>>
>>>> +
>>>> +#ifdef CONFIG_RESET_CONTROLLER
>>>> +int __init hisi_reset_init(struct device_node *np);
>>>
>>> We don't need __init in header files.
>>>
>> OK. I'll remove it. Thank you.
>>
>> Jiancheng
>> .
>>
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-14 13:16 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-14 13:16 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: p.zabel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, linux, khilman, arnd, olof, xuwei5, haojian.zhuang,
zhangfei.gao, bintian.wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng, yanghongwei, suwenping, ml.yang,
gaofei, zhangzhenxing, xuejiancheng
Hi Mike,
On 2016/1/14 2:57, Michael Turquette wrote:
> Quoting xuejiancheng (2016-01-12 19:03:01)
>> Hi Stephen,
>> Thank you very much for your reply.
>>
>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>> On 01/08, Jiancheng Xue wrote:
>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>> index e434854..b6baebf 100644
>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>> @@ -1,3 +1,10 @@
>>>> +config COMMON_CLK_HI3519
>>>> + tristate "Clock Driver for Hi3519"
>>>
>>> It looks like this has to be bool. Otherwise it needs to be a
>>> platform driver and the hisilicon APIs need to be exported and
>>> lose their __init markings.
>>>
>> Yes,it's a problem. I will fix it in next version. Thank you.
>
> The best solution would be to make this clock driver a real platform
> driver.
>
Now the work clock of the clocksource timer-sp804 is provided by this driver. So
it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
as a fixed-clock provider, this driver can be implemented as a platform driver.
Then the crg device must be registered before other clock consumer devices.Accordingly
the crg device node must be written above all other clock consumer devices node in dts files.
I think it is also a dependence.
Can you help me understand why it is better to make this driver a platform driver?
Thank you very much!
> Regards,
> Mike
>
>>
>>>> + depends on ARCH_HISI
>>>> + default y
>>>> + help
>>>> + Build the clock driver for hi3519.
>>>> +
>>>> config COMMON_CLK_HI6220
>>>> bool "Hi6220 Clock Driver"
>>>> depends on ARCH_HISI || COMPILE_TEST
>>>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>>>> new file mode 100644
>>>> index 0000000..72d3a7b0
>>>> --- /dev/null
>>>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>>>> @@ -0,0 +1,105 @@
>>>> +
>>>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>>>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>>>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>>>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>>>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>>>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>>>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>>>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>>>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>>>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>>>> +
>>>> +#define HI3519_NR_CLKS 128
>>>
>>> Is this the same clock provider as the external clocks? I don't
>>> understand why we're offsetting the clock numbering if we have
>>> different providers. And if these are truly fixed clocks (except
>>> for the mux) perhaps they're not even provided by this hardware
>>> block, and are clocks that come from the board? If that's true
>>> then I would expect them to be described in DT as fixed rate
>>> clocks.
>>>
>> External clocks mentioned here are used directly as work clocks of other modules.
>> Clocks defined in this file (internal clocks) are used as parents of external
>> clocks. Internal clocks won't be referred by dts files and are just used in this driver.
>> So they are moved here from the header file.
>>
>> External clocks and internal clocks are all generated by this CRG block. The input clock
>> of the CRG block is always connected to a crystal oscillator on the board. So only one
>> clock provider is defined here.
>>
>> Some clocks generated by CRG won't change their rate during the system running. These clocks
>> are treated as fixed clocks here.
>>
>>>> +
>>>> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
>>>> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
>>>> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
>>>> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
>>>> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
>>>> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
>>>> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
>>>> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
>>>> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
>>>> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
>>>> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
>>>> +};
>>>> +
>>>> +static const char *fmc_mux_p[] __initconst = {
>>>
>>> const char * const ?
>>>
>>
>> OK.
>>
>>>> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
>>>> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
>>>> +
>>>> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
>>>> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
>>>> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
>>>> +};
>>>> +
>>>> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
>>>
>>> We should look into making these things const.
>>>
>> OK. I'll add this in next version.
>>
>>>> + /* fmc */
>>>> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
>>>> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
>>>> + /* uart */
>>>> + { HI3519_UART0_CLK, "clk_uart0", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
>>>> + { HI3519_UART1_CLK, "clk_uart1", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
>>>> + { HI3519_UART2_CLK, "clk_uart2", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
>>>> + { HI3519_UART3_CLK, "clk_uart3", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
>>>> + { HI3519_UART4_CLK, "clk_uart4", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
>>>> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
>>>> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
>>>> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
>>>> +};
>>>> +
>>>> +static void __init hi3519_clk_init(struct device_node *np)
>>>> +{
>>>> + struct hisi_clock_data *clk_data;
>>>> +
>>>> +
>>>> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
>>>> + if (!clk_data)
>>>> + return;
>>>> +
>>>> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
>>>> + ARRAY_SIZE(hi3519_fixed_rate_clks),
>>>> + clk_data);
>>>> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
>>>> + clk_data);
>>>> + hisi_clk_register_gate(hi3519_gate_clks,
>>>> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
>>>> +
>>>> + hisi_reset_init(np);
>>>> +}
>>>> +
>>>> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
>>>> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
>>>> new file mode 100644
>>>> index 0000000..37856089
>>>> --- /dev/null
>>>> +++ b/drivers/clk/hisilicon/reset.h
>>>> @@ -0,0 +1,32 @@
>>>> +/*
>>>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License as published by
>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>> + * (at your option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>>>> + */
>>>> +
>>>> +#ifndef __HISI_RESET_H
>>>> +#define __HISI_RESET_H
>>>> +
>>>> +#include <linux/of.h>
>>>
>>> Drop this include and forward declare struct device_node instead.
>>>
>>
>> OK.
>>
>>>> +
>>>> +#ifdef CONFIG_RESET_CONTROLLER
>>>> +int __init hisi_reset_init(struct device_node *np);
>>>
>>> We don't need __init in header files.
>>>
>> OK. I'll remove it. Thank you.
>>
>> Jiancheng
>> .
>>
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-14 13:16 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-14 13:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mike,
On 2016/1/14 2:57, Michael Turquette wrote:
> Quoting xuejiancheng (2016-01-12 19:03:01)
>> Hi Stephen,
>> Thank you very much for your reply.
>>
>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>> On 01/08, Jiancheng Xue wrote:
>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>> index e434854..b6baebf 100644
>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>> @@ -1,3 +1,10 @@
>>>> +config COMMON_CLK_HI3519
>>>> + tristate "Clock Driver for Hi3519"
>>>
>>> It looks like this has to be bool. Otherwise it needs to be a
>>> platform driver and the hisilicon APIs need to be exported and
>>> lose their __init markings.
>>>
>> Yes,it's a problem. I will fix it in next version. Thank you.
>
> The best solution would be to make this clock driver a real platform
> driver.
>
Now the work clock of the clocksource timer-sp804 is provided by this driver. So
it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
as a fixed-clock provider, this driver can be implemented as a platform driver.
Then the crg device must be registered before other clock consumer devices.Accordingly
the crg device node must be written above all other clock consumer devices node in dts files.
I think it is also a dependence.
Can you help me understand why it is better to make this driver a platform driver?
Thank you very much!
> Regards,
> Mike
>
>>
>>>> + depends on ARCH_HISI
>>>> + default y
>>>> + help
>>>> + Build the clock driver for hi3519.
>>>> +
>>>> config COMMON_CLK_HI6220
>>>> bool "Hi6220 Clock Driver"
>>>> depends on ARCH_HISI || COMPILE_TEST
>>>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>>>> new file mode 100644
>>>> index 0000000..72d3a7b0
>>>> --- /dev/null
>>>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>>>> @@ -0,0 +1,105 @@
>>>> +
>>>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>>>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>>>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>>>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>>>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>>>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>>>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>>>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>>>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>>>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>>>> +
>>>> +#define HI3519_NR_CLKS 128
>>>
>>> Is this the same clock provider as the external clocks? I don't
>>> understand why we're offsetting the clock numbering if we have
>>> different providers. And if these are truly fixed clocks (except
>>> for the mux) perhaps they're not even provided by this hardware
>>> block, and are clocks that come from the board? If that's true
>>> then I would expect them to be described in DT as fixed rate
>>> clocks.
>>>
>> External clocks mentioned here are used directly as work clocks of other modules.
>> Clocks defined in this file (internal clocks) are used as parents of external
>> clocks. Internal clocks won't be referred by dts files and are just used in this driver.
>> So they are moved here from the header file.
>>
>> External clocks and internal clocks are all generated by this CRG block. The input clock
>> of the CRG block is always connected to a crystal oscillator on the board. So only one
>> clock provider is defined here.
>>
>> Some clocks generated by CRG won't change their rate during the system running. These clocks
>> are treated as fixed clocks here.
>>
>>>> +
>>>> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
>>>> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
>>>> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
>>>> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
>>>> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
>>>> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
>>>> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
>>>> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
>>>> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
>>>> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
>>>> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
>>>> +};
>>>> +
>>>> +static const char *fmc_mux_p[] __initconst = {
>>>
>>> const char * const ?
>>>
>>
>> OK.
>>
>>>> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
>>>> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
>>>> +
>>>> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
>>>> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
>>>> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
>>>> +};
>>>> +
>>>> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
>>>
>>> We should look into making these things const.
>>>
>> OK. I'll add this in next version.
>>
>>>> + /* fmc */
>>>> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
>>>> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
>>>> + /* uart */
>>>> + { HI3519_UART0_CLK, "clk_uart0", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
>>>> + { HI3519_UART1_CLK, "clk_uart1", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
>>>> + { HI3519_UART2_CLK, "clk_uart2", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
>>>> + { HI3519_UART3_CLK, "clk_uart3", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
>>>> + { HI3519_UART4_CLK, "clk_uart4", "24m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
>>>> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
>>>> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
>>>> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
>>>> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
>>>> +};
>>>> +
>>>> +static void __init hi3519_clk_init(struct device_node *np)
>>>> +{
>>>> + struct hisi_clock_data *clk_data;
>>>> +
>>>> +
>>>> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
>>>> + if (!clk_data)
>>>> + return;
>>>> +
>>>> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
>>>> + ARRAY_SIZE(hi3519_fixed_rate_clks),
>>>> + clk_data);
>>>> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
>>>> + clk_data);
>>>> + hisi_clk_register_gate(hi3519_gate_clks,
>>>> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
>>>> +
>>>> + hisi_reset_init(np);
>>>> +}
>>>> +
>>>> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
>>>> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
>>>> new file mode 100644
>>>> index 0000000..37856089
>>>> --- /dev/null
>>>> +++ b/drivers/clk/hisilicon/reset.h
>>>> @@ -0,0 +1,32 @@
>>>> +/*
>>>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License as published by
>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>> + * (at your option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>>>> + */
>>>> +
>>>> +#ifndef __HISI_RESET_H
>>>> +#define __HISI_RESET_H
>>>> +
>>>> +#include <linux/of.h>
>>>
>>> Drop this include and forward declare struct device_node instead.
>>>
>>
>> OK.
>>
>>>> +
>>>> +#ifdef CONFIG_RESET_CONTROLLER
>>>> +int __init hisi_reset_init(struct device_node *np);
>>>
>>> We don't need __init in header files.
>>>
>> OK. I'll remove it. Thank you.
>>
>> Jiancheng
>> .
>>
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-14 13:16 ` xuejiancheng
(?)
@ 2016-01-15 7:57 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-15 7:57 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: p.zabel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, linux, khilman, arnd, olof, xuwei5, haojian.zhuang,
zhangfei.gao, bintian.wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng, yanghongwei, suwenping, ml.yang,
gaofei, zhangzhenxing, xuejiancheng
On 2016/1/14 21:16, xuejiancheng wrote:
> Hi Mike,
>
> On 2016/1/14 2:57, Michael Turquette wrote:
>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>> Hi Stephen,
>>> Thank you very much for your reply.
>>>
>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>> On 01/08, Jiancheng Xue wrote:
>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>> index e434854..b6baebf 100644
>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>> @@ -1,3 +1,10 @@
>>>>> +config COMMON_CLK_HI3519
>>>>> + tristate "Clock Driver for Hi3519"
>>>>
>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>> platform driver and the hisilicon APIs need to be exported and
>>>> lose their __init markings.
>>>>
>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>
>> The best solution would be to make this clock driver a real platform
>> driver.
>>
> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
> as a fixed-clock provider, this driver can be implemented as a platform driver.
> Then the crg device must be registered before other clock consumer devices.Accordingly
> the crg device node must be written above all other clock consumer devices node in dts files.
> I think it is also a dependence.
>
> Can you help me understand why it is better to make this driver a platform driver?
> Thank you very much!
>
arch_initcall(customize_machine)
-->of_platform_populate
-->of_platform_bus_create
-->of_amba_device_create
-->amba_device_add
-->amba_get_enable_pclk
The call sequence above shows that the clock of the amba device must be registered before
amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
the amba device "arm,pl011" uart.
If this is not a problem, I'll change this to a platform driver in next version.
Thank you.
Regards，
Jiancheng
>> Regards,
>> Mike
>>
>>>
>>>>> + depends on ARCH_HISI
>>>>> + default y
>>>>> + help
>>>>> + Build the clock driver for hi3519.
>>>>> +
>>>>> config COMMON_CLK_HI6220
>>>>> bool "Hi6220 Clock Driver"
>>>>> depends on ARCH_HISI || COMPILE_TEST
>>>>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>>>>> new file mode 100644
>>>>> index 0000000..72d3a7b0
>>>>> --- /dev/null
>>>>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>>>>> @@ -0,0 +1,105 @@
>>>>> +
>>>>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>>>>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>>>>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>>>>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>>>>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>>>>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>>>>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>>>>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>>>>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>>>>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>>>>> +
>>>>> +#define HI3519_NR_CLKS 128
>>>>
>>>> Is this the same clock provider as the external clocks? I don't
>>>> understand why we're offsetting the clock numbering if we have
>>>> different providers. And if these are truly fixed clocks (except
>>>> for the mux) perhaps they're not even provided by this hardware
>>>> block, and are clocks that come from the board? If that's true
>>>> then I would expect them to be described in DT as fixed rate
>>>> clocks.
>>>>
>>> External clocks mentioned here are used directly as work clocks of other modules.
>>> Clocks defined in this file (internal clocks) are used as parents of external
>>> clocks. Internal clocks won't be referred by dts files and are just used in this driver.
>>> So they are moved here from the header file.
>>>
>>> External clocks and internal clocks are all generated by this CRG block. The input clock
>>> of the CRG block is always connected to a crystal oscillator on the board. So only one
>>> clock provider is defined here.
>>>
>>> Some clocks generated by CRG won't change their rate during the system running. These clocks
>>> are treated as fixed clocks here.
>>>
>>>>> +
>>>>> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
>>>>> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
>>>>> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
>>>>> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
>>>>> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
>>>>> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
>>>>> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
>>>>> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
>>>>> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
>>>>> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
>>>>> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
>>>>> +};
>>>>> +
>>>>> +static const char *fmc_mux_p[] __initconst = {
>>>>
>>>> const char * const ?
>>>>
>>>
>>> OK.
>>>
>>>>> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
>>>>> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
>>>>> +
>>>>> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
>>>>> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
>>>>> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
>>>>> +};
>>>>> +
>>>>> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
>>>>
>>>> We should look into making these things const.
>>>>
>>> OK. I'll add this in next version.
>>>
>>>>> + /* fmc */
>>>>> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
>>>>> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
>>>>> + /* uart */
>>>>> + { HI3519_UART0_CLK, "clk_uart0", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
>>>>> + { HI3519_UART1_CLK, "clk_uart1", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
>>>>> + { HI3519_UART2_CLK, "clk_uart2", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
>>>>> + { HI3519_UART3_CLK, "clk_uart3", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
>>>>> + { HI3519_UART4_CLK, "clk_uart4", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
>>>>> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
>>>>> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
>>>>> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
>>>>> +};
>>>>> +
>>>>> +static void __init hi3519_clk_init(struct device_node *np)
>>>>> +{
>>>>> + struct hisi_clock_data *clk_data;
>>>>> +
>>>>> +
>>>>> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
>>>>> + if (!clk_data)
>>>>> + return;
>>>>> +
>>>>> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
>>>>> + ARRAY_SIZE(hi3519_fixed_rate_clks),
>>>>> + clk_data);
>>>>> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
>>>>> + clk_data);
>>>>> + hisi_clk_register_gate(hi3519_gate_clks,
>>>>> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
>>>>> +
>>>>> + hisi_reset_init(np);
>>>>> +}
>>>>> +
>>>>> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
>>>>> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
>>>>> new file mode 100644
>>>>> index 0000000..37856089
>>>>> --- /dev/null
>>>>> +++ b/drivers/clk/hisilicon/reset.h
>>>>> @@ -0,0 +1,32 @@
>>>>> +/*
>>>>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>>>>> + *
>>>>> + * This program is free software; you can redistribute it and/or modify
>>>>> + * it under the terms of the GNU General Public License as published by
>>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>>> + * (at your option) any later version.
>>>>> + *
>>>>> + * This program is distributed in the hope that it will be useful,
>>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>>> + * GNU General Public License for more details.
>>>>> + *
>>>>> + * You should have received a copy of the GNU General Public License
>>>>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>>>>> + */
>>>>> +
>>>>> +#ifndef __HISI_RESET_H
>>>>> +#define __HISI_RESET_H
>>>>> +
>>>>> +#include <linux/of.h>
>>>>
>>>> Drop this include and forward declare struct device_node instead.
>>>>
>>>
>>> OK.
>>>
>>>>> +
>>>>> +#ifdef CONFIG_RESET_CONTROLLER
>>>>> +int __init hisi_reset_init(struct device_node *np);
>>>>
>>>> We don't need __init in header files.
>>>>
>>> OK. I'll remove it. Thank you.
>>>
>>> Jiancheng
>>> .
>>>
>>
>> .
>>
>
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-15 7:57 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-15 7:57 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: p.zabel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, linux, khilman, arnd, olof, xuwei5, haojian.zhuang,
zhangfei.gao, bintian.wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng, yanghongwei, suwenping, ml.yang,
gaofei, zhangzhenxing, xuejiancheng
On 2016/1/14 21:16, xuejiancheng wrote:
> Hi Mike,
>
> On 2016/1/14 2:57, Michael Turquette wrote:
>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>> Hi Stephen,
>>> Thank you very much for your reply.
>>>
>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>> On 01/08, Jiancheng Xue wrote:
>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>> index e434854..b6baebf 100644
>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>> @@ -1,3 +1,10 @@
>>>>> +config COMMON_CLK_HI3519
>>>>> + tristate "Clock Driver for Hi3519"
>>>>
>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>> platform driver and the hisilicon APIs need to be exported and
>>>> lose their __init markings.
>>>>
>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>
>> The best solution would be to make this clock driver a real platform
>> driver.
>>
> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
> as a fixed-clock provider, this driver can be implemented as a platform driver.
> Then the crg device must be registered before other clock consumer devices.Accordingly
> the crg device node must be written above all other clock consumer devices node in dts files.
> I think it is also a dependence.
>
> Can you help me understand why it is better to make this driver a platform driver?
> Thank you very much!
>
arch_initcall(customize_machine)
-->of_platform_populate
-->of_platform_bus_create
-->of_amba_device_create
-->amba_device_add
-->amba_get_enable_pclk
The call sequence above shows that the clock of the amba device must be registered before
amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
the amba device "arm,pl011" uart.
If this is not a problem, I'll change this to a platform driver in next version.
Thank you.
Regards，
Jiancheng
>> Regards,
>> Mike
>>
>>>
>>>>> + depends on ARCH_HISI
>>>>> + default y
>>>>> + help
>>>>> + Build the clock driver for hi3519.
>>>>> +
>>>>> config COMMON_CLK_HI6220
>>>>> bool "Hi6220 Clock Driver"
>>>>> depends on ARCH_HISI || COMPILE_TEST
>>>>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>>>>> new file mode 100644
>>>>> index 0000000..72d3a7b0
>>>>> --- /dev/null
>>>>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>>>>> @@ -0,0 +1,105 @@
>>>>> +
>>>>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>>>>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>>>>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>>>>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>>>>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>>>>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>>>>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>>>>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>>>>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>>>>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>>>>> +
>>>>> +#define HI3519_NR_CLKS 128
>>>>
>>>> Is this the same clock provider as the external clocks? I don't
>>>> understand why we're offsetting the clock numbering if we have
>>>> different providers. And if these are truly fixed clocks (except
>>>> for the mux) perhaps they're not even provided by this hardware
>>>> block, and are clocks that come from the board? If that's true
>>>> then I would expect them to be described in DT as fixed rate
>>>> clocks.
>>>>
>>> External clocks mentioned here are used directly as work clocks of other modules.
>>> Clocks defined in this file (internal clocks) are used as parents of external
>>> clocks. Internal clocks won't be referred by dts files and are just used in this driver.
>>> So they are moved here from the header file.
>>>
>>> External clocks and internal clocks are all generated by this CRG block. The input clock
>>> of the CRG block is always connected to a crystal oscillator on the board. So only one
>>> clock provider is defined here.
>>>
>>> Some clocks generated by CRG won't change their rate during the system running. These clocks
>>> are treated as fixed clocks here.
>>>
>>>>> +
>>>>> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
>>>>> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
>>>>> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
>>>>> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
>>>>> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
>>>>> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
>>>>> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
>>>>> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
>>>>> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
>>>>> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
>>>>> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
>>>>> +};
>>>>> +
>>>>> +static const char *fmc_mux_p[] __initconst = {
>>>>
>>>> const char * const ?
>>>>
>>>
>>> OK.
>>>
>>>>> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
>>>>> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
>>>>> +
>>>>> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
>>>>> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
>>>>> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
>>>>> +};
>>>>> +
>>>>> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
>>>>
>>>> We should look into making these things const.
>>>>
>>> OK. I'll add this in next version.
>>>
>>>>> + /* fmc */
>>>>> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
>>>>> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
>>>>> + /* uart */
>>>>> + { HI3519_UART0_CLK, "clk_uart0", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
>>>>> + { HI3519_UART1_CLK, "clk_uart1", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
>>>>> + { HI3519_UART2_CLK, "clk_uart2", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
>>>>> + { HI3519_UART3_CLK, "clk_uart3", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
>>>>> + { HI3519_UART4_CLK, "clk_uart4", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
>>>>> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
>>>>> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
>>>>> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
>>>>> +};
>>>>> +
>>>>> +static void __init hi3519_clk_init(struct device_node *np)
>>>>> +{
>>>>> + struct hisi_clock_data *clk_data;
>>>>> +
>>>>> +
>>>>> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
>>>>> + if (!clk_data)
>>>>> + return;
>>>>> +
>>>>> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
>>>>> + ARRAY_SIZE(hi3519_fixed_rate_clks),
>>>>> + clk_data);
>>>>> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
>>>>> + clk_data);
>>>>> + hisi_clk_register_gate(hi3519_gate_clks,
>>>>> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
>>>>> +
>>>>> + hisi_reset_init(np);
>>>>> +}
>>>>> +
>>>>> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
>>>>> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
>>>>> new file mode 100644
>>>>> index 0000000..37856089
>>>>> --- /dev/null
>>>>> +++ b/drivers/clk/hisilicon/reset.h
>>>>> @@ -0,0 +1,32 @@
>>>>> +/*
>>>>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>>>>> + *
>>>>> + * This program is free software; you can redistribute it and/or modify
>>>>> + * it under the terms of the GNU General Public License as published by
>>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>>> + * (at your option) any later version.
>>>>> + *
>>>>> + * This program is distributed in the hope that it will be useful,
>>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>>> + * GNU General Public License for more details.
>>>>> + *
>>>>> + * You should have received a copy of the GNU General Public License
>>>>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>>>>> + */
>>>>> +
>>>>> +#ifndef __HISI_RESET_H
>>>>> +#define __HISI_RESET_H
>>>>> +
>>>>> +#include <linux/of.h>
>>>>
>>>> Drop this include and forward declare struct device_node instead.
>>>>
>>>
>>> OK.
>>>
>>>>> +
>>>>> +#ifdef CONFIG_RESET_CONTROLLER
>>>>> +int __init hisi_reset_init(struct device_node *np);
>>>>
>>>> We don't need __init in header files.
>>>>
>>> OK. I'll remove it. Thank you.
>>>
>>> Jiancheng
>>> .
>>>
>>
>> .
>>
>
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-15 7:57 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-15 7:57 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/14 21:16, xuejiancheng wrote:
> Hi Mike,
>
> On 2016/1/14 2:57, Michael Turquette wrote:
>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>> Hi Stephen,
>>> Thank you very much for your reply.
>>>
>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>> On 01/08, Jiancheng Xue wrote:
>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>> index e434854..b6baebf 100644
>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>> @@ -1,3 +1,10 @@
>>>>> +config COMMON_CLK_HI3519
>>>>> + tristate "Clock Driver for Hi3519"
>>>>
>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>> platform driver and the hisilicon APIs need to be exported and
>>>> lose their __init markings.
>>>>
>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>
>> The best solution would be to make this clock driver a real platform
>> driver.
>>
> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
> as a fixed-clock provider, this driver can be implemented as a platform driver.
> Then the crg device must be registered before other clock consumer devices.Accordingly
> the crg device node must be written above all other clock consumer devices node in dts files.
> I think it is also a dependence.
>
> Can you help me understand why it is better to make this driver a platform driver?
> Thank you very much!
>
arch_initcall(customize_machine)
-->of_platform_populate
-->of_platform_bus_create
-->of_amba_device_create
-->amba_device_add
-->amba_get_enable_pclk
The call sequence above shows that the clock of the amba device must be registered before
amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
the amba device "arm,pl011" uart.
If this is not a problem, I'll change this to a platform driver in next version.
Thank you.
Regards?
Jiancheng
>> Regards,
>> Mike
>>
>>>
>>>>> + depends on ARCH_HISI
>>>>> + default y
>>>>> + help
>>>>> + Build the clock driver for hi3519.
>>>>> +
>>>>> config COMMON_CLK_HI6220
>>>>> bool "Hi6220 Clock Driver"
>>>>> depends on ARCH_HISI || COMPILE_TEST
>>>>> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
>>>>> new file mode 100644
>>>>> index 0000000..72d3a7b0
>>>>> --- /dev/null
>>>>> +++ b/drivers/clk/hisilicon/clk-hi3519.c
>>>>> @@ -0,0 +1,105 @@
>>>>> +
>>>>> +#define HI3519_FIXED_24M (HI3519_EXT_CLKS + 1)
>>>>> +#define HI3519_FIXED_50M (HI3519_EXT_CLKS + 2)
>>>>> +#define HI3519_FIXED_75M (HI3519_EXT_CLKS + 3)
>>>>> +#define HI3519_FIXED_125M (HI3519_EXT_CLKS + 4)
>>>>> +#define HI3519_FIXED_150M (HI3519_EXT_CLKS + 5)
>>>>> +#define HI3519_FIXED_200M (HI3519_EXT_CLKS + 6)
>>>>> +#define HI3519_FIXED_250M (HI3519_EXT_CLKS + 7)
>>>>> +#define HI3519_FIXED_300M (HI3519_EXT_CLKS + 8)
>>>>> +#define HI3519_FIXED_400M (HI3519_EXT_CLKS + 9)
>>>>> +#define HI3519_FMC_MUX (HI3519_EXT_CLKS + 10)
>>>>> +
>>>>> +#define HI3519_NR_CLKS 128
>>>>
>>>> Is this the same clock provider as the external clocks? I don't
>>>> understand why we're offsetting the clock numbering if we have
>>>> different providers. And if these are truly fixed clocks (except
>>>> for the mux) perhaps they're not even provided by this hardware
>>>> block, and are clocks that come from the board? If that's true
>>>> then I would expect them to be described in DT as fixed rate
>>>> clocks.
>>>>
>>> External clocks mentioned here are used directly as work clocks of other modules.
>>> Clocks defined in this file (internal clocks) are used as parents of external
>>> clocks. Internal clocks won't be referred by dts files and are just used in this driver.
>>> So they are moved here from the header file.
>>>
>>> External clocks and internal clocks are all generated by this CRG block. The input clock
>>> of the CRG block is always connected to a crystal oscillator on the board. So only one
>>> clock provider is defined here.
>>>
>>> Some clocks generated by CRG won't change their rate during the system running. These clocks
>>> are treated as fixed clocks here.
>>>
>>>>> +
>>>>> +static struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] __initdata = {
>>>>> + { HI3519_FIXED_3M, "3m", NULL, CLK_IS_ROOT, 3000000, },
>>>>> + { HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
>>>>> + { HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
>>>>> + { HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
>>>>> + { HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
>>>>> + { HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
>>>>> + { HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
>>>>> + { HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
>>>>> + { HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
>>>>> + { HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
>>>>> +};
>>>>> +
>>>>> +static const char *fmc_mux_p[] __initconst = {
>>>>
>>>> const char * const ?
>>>>
>>>
>>> OK.
>>>
>>>>> + "24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
>>>>> +static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
>>>>> +
>>>>> +static struct hisi_mux_clock hi3519_mux_clks[] __initdata = {
>>>>> + { HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
>>>>> + CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
>>>>> +};
>>>>> +
>>>>> +static struct hisi_gate_clock hi3519_gate_clks[] __initdata = {
>>>>
>>>> We should look into making these things const.
>>>>
>>> OK. I'll add this in next version.
>>>
>>>>> + /* fmc */
>>>>> + { HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
>>>>> + CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
>>>>> + /* uart */
>>>>> + { HI3519_UART0_CLK, "clk_uart0", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
>>>>> + { HI3519_UART1_CLK, "clk_uart1", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
>>>>> + { HI3519_UART2_CLK, "clk_uart2", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
>>>>> + { HI3519_UART3_CLK, "clk_uart3", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
>>>>> + { HI3519_UART4_CLK, "clk_uart4", "24m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
>>>>> + { HI3519_SPI0_CLK, "clk_spi0", "50m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
>>>>> + { HI3519_SPI1_CLK, "clk_spi1", "50m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
>>>>> + { HI3519_SPI2_CLK, "clk_spi2", "50m",
>>>>> + CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
>>>>> +};
>>>>> +
>>>>> +static void __init hi3519_clk_init(struct device_node *np)
>>>>> +{
>>>>> + struct hisi_clock_data *clk_data;
>>>>> +
>>>>> +
>>>>> + clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
>>>>> + if (!clk_data)
>>>>> + return;
>>>>> +
>>>>> + hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
>>>>> + ARRAY_SIZE(hi3519_fixed_rate_clks),
>>>>> + clk_data);
>>>>> + hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
>>>>> + clk_data);
>>>>> + hisi_clk_register_gate(hi3519_gate_clks,
>>>>> + ARRAY_SIZE(hi3519_gate_clks), clk_data);
>>>>> +
>>>>> + hisi_reset_init(np);
>>>>> +}
>>>>> +
>>>>> +CLK_OF_DECLARE(hi3519_clk, "hisilicon,hi3519-crg", hi3519_clk_init);
>>>>> diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
>>>>> new file mode 100644
>>>>> index 0000000..37856089
>>>>> --- /dev/null
>>>>> +++ b/drivers/clk/hisilicon/reset.h
>>>>> @@ -0,0 +1,32 @@
>>>>> +/*
>>>>> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
>>>>> + *
>>>>> + * This program is free software; you can redistribute it and/or modify
>>>>> + * it under the terms of the GNU General Public License as published by
>>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>>> + * (at your option) any later version.
>>>>> + *
>>>>> + * This program is distributed in the hope that it will be useful,
>>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>>> + * GNU General Public License for more details.
>>>>> + *
>>>>> + * You should have received a copy of the GNU General Public License
>>>>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>>>>> + */
>>>>> +
>>>>> +#ifndef __HISI_RESET_H
>>>>> +#define __HISI_RESET_H
>>>>> +
>>>>> +#include <linux/of.h>
>>>>
>>>> Drop this include and forward declare struct device_node instead.
>>>>
>>>
>>> OK.
>>>
>>>>> +
>>>>> +#ifdef CONFIG_RESET_CONTROLLER
>>>>> +int __init hisi_reset_init(struct device_node *np);
>>>>
>>>> We don't need __init in header files.
>>>>
>>> OK. I'll remove it. Thank you.
>>>
>>> Jiancheng
>>> .
>>>
>>
>> .
>>
>
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-15 7:57 ` xuejiancheng
(?)
(?)
@ 2016-01-19 18:20 ` Rob Herring
-1 siblings, 0 replies; 103+ messages in thread
From: Rob Herring @ 2016-01-19 18:20 UTC (permalink / raw)
To: xuejiancheng, Tomeu Vizoso
Cc: Michael Turquette, Stephen Boyd, Philipp Zabel, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King - ARM Linux,
Kevin Hilman, Arnd Bergmann, Olof Johansson, Wei Xu,
Haojian Zhuang, Zhangfei Gao, Bintian Wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>
> On 2016/1/14 21:16, xuejiancheng wrote:
>> Hi Mike,
>>
>> On 2016/1/14 2:57, Michael Turquette wrote:
>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>> Hi Stephen,
>>>> Thank you very much for your reply.
>>>>
>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>> index e434854..b6baebf 100644
>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>> @@ -1,3 +1,10 @@
>>>>>> +config COMMON_CLK_HI3519
>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>
>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>> lose their __init markings.
>>>>>
>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>
>>> The best solution would be to make this clock driver a real platform
>>> driver.
>>>
>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>> Then the crg device must be registered before other clock consumer devices.Accordingly
>> the crg device node must be written above all other clock consumer devices node in dts files.
>> I think it is also a dependence.
>>
>> Can you help me understand why it is better to make this driver a platform driver?
>> Thank you very much!
>>
> arch_initcall(customize_machine)
> -->of_platform_populate
> -->of_platform_bus_create
> -->of_amba_device_create
> -->amba_device_add
> -->amba_get_enable_pclk
> The call sequence above shows that the clock of the amba device must be registered before
> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
> the amba device "arm,pl011" uart.
It is a problem, but Tomeu had a fix to support deferred probes here.
That was part of the on-demand probing series, but maybe it needs to
be applied separately if we are moving clock drivers to platform
drivers.
Rob
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-19 18:20 ` Rob Herring
0 siblings, 0 replies; 103+ messages in thread
From: Rob Herring @ 2016-01-19 18:20 UTC (permalink / raw)
To: xuejiancheng, Tomeu Vizoso
Cc: Michael Turquette, Stephen Boyd, Philipp Zabel, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King - ARM Linux,
Kevin Hilman, Arnd Bergmann, Olof Johansson, Wei Xu,
Haojian Zhuang, Zhangfei Gao, Bintian Wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwen
On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>
> On 2016/1/14 21:16, xuejiancheng wrote:
>> Hi Mike,
>>
>> On 2016/1/14 2:57, Michael Turquette wrote:
>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>> Hi Stephen,
>>>> Thank you very much for your reply.
>>>>
>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>> index e434854..b6baebf 100644
>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>> @@ -1,3 +1,10 @@
>>>>>> +config COMMON_CLK_HI3519
>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>
>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>> lose their __init markings.
>>>>>
>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>
>>> The best solution would be to make this clock driver a real platform
>>> driver.
>>>
>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>> Then the crg device must be registered before other clock consumer devices.Accordingly
>> the crg device node must be written above all other clock consumer devices node in dts files.
>> I think it is also a dependence.
>>
>> Can you help me understand why it is better to make this driver a platform driver?
>> Thank you very much!
>>
> arch_initcall(customize_machine)
> -->of_platform_populate
> -->of_platform_bus_create
> -->of_amba_device_create
> -->amba_device_add
> -->amba_get_enable_pclk
> The call sequence above shows that the clock of the amba device must be registered before
> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
> the amba device "arm,pl011" uart.
It is a problem, but Tomeu had a fix to support deferred probes here.
That was part of the on-demand probing series, but maybe it needs to
be applied separately if we are moving clock drivers to platform
drivers.
Rob
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-19 18:20 ` Rob Herring
0 siblings, 0 replies; 103+ messages in thread
From: Rob Herring @ 2016-01-19 18:20 UTC (permalink / raw)
To: xuejiancheng, Tomeu Vizoso
Cc: Michael Turquette, Stephen Boyd, Philipp Zabel, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King - ARM Linux,
Kevin Hilman, Arnd Bergmann, Olof Johansson, Wei Xu,
Haojian Zhuang, Zhangfei Gao, Bintian Wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>
> On 2016/1/14 21:16, xuejiancheng wrote:
>> Hi Mike,
>>
>> On 2016/1/14 2:57, Michael Turquette wrote:
>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>> Hi Stephen,
>>>> Thank you very much for your reply.
>>>>
>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>> index e434854..b6baebf 100644
>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>> @@ -1,3 +1,10 @@
>>>>>> +config COMMON_CLK_HI3519
>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>
>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>> lose their __init markings.
>>>>>
>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>
>>> The best solution would be to make this clock driver a real platform
>>> driver.
>>>
>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>> Then the crg device must be registered before other clock consumer devices.Accordingly
>> the crg device node must be written above all other clock consumer devices node in dts files.
>> I think it is also a dependence.
>>
>> Can you help me understand why it is better to make this driver a platform driver?
>> Thank you very much!
>>
> arch_initcall(customize_machine)
> -->of_platform_populate
> -->of_platform_bus_create
> -->of_amba_device_create
> -->amba_device_add
> -->amba_get_enable_pclk
> The call sequence above shows that the clock of the amba device must be registered before
> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
> the amba device "arm,pl011" uart.
It is a problem, but Tomeu had a fix to support deferred probes here.
That was part of the on-demand probing series, but maybe it needs to
be applied separately if we are moving clock drivers to platform
drivers.
Rob
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-19 18:20 ` Rob Herring
0 siblings, 0 replies; 103+ messages in thread
From: Rob Herring @ 2016-01-19 18:20 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>
> On 2016/1/14 21:16, xuejiancheng wrote:
>> Hi Mike,
>>
>> On 2016/1/14 2:57, Michael Turquette wrote:
>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>> Hi Stephen,
>>>> Thank you very much for your reply.
>>>>
>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>> index e434854..b6baebf 100644
>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>> @@ -1,3 +1,10 @@
>>>>>> +config COMMON_CLK_HI3519
>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>
>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>> lose their __init markings.
>>>>>
>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>
>>> The best solution would be to make this clock driver a real platform
>>> driver.
>>>
>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>> Then the crg device must be registered before other clock consumer devices.Accordingly
>> the crg device node must be written above all other clock consumer devices node in dts files.
>> I think it is also a dependence.
>>
>> Can you help me understand why it is better to make this driver a platform driver?
>> Thank you very much!
>>
> arch_initcall(customize_machine)
> -->of_platform_populate
> -->of_platform_bus_create
> -->of_amba_device_create
> -->amba_device_add
> -->amba_get_enable_pclk
> The call sequence above shows that the clock of the amba device must be registered before
> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
> the amba device "arm,pl011" uart.
It is a problem, but Tomeu had a fix to support deferred probes here.
That was part of the on-demand probing series, but maybe it needs to
be applied separately if we are moving clock drivers to platform
drivers.
Rob
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-19 18:20 ` Rob Herring
(?)
(?)
@ 2016-01-20 6:38 ` Tomeu Vizoso
-1 siblings, 0 replies; 103+ messages in thread
From: Tomeu Vizoso @ 2016-01-20 6:38 UTC (permalink / raw)
To: Rob Herring
Cc: xuejiancheng, Michael Turquette, Stephen Boyd, Philipp Zabel,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King - ARM Linux, Kevin Hilman, Arnd Bergmann,
Olof Johansson, Wei Xu, Haojian Zhuang, Zhangfei Gao,
Bintian Wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng, yanghongwei, suwenping, ml.yang,
gaofei, zhangzhenxing, xuejiancheng
On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>
>> On 2016/1/14 21:16, xuejiancheng wrote:
>>> Hi Mike,
>>>
>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>> Hi Stephen,
>>>>> Thank you very much for your reply.
>>>>>
>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>> index e434854..b6baebf 100644
>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>> @@ -1,3 +1,10 @@
>>>>>>> +config COMMON_CLK_HI3519
>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>
>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>> lose their __init markings.
>>>>>>
>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>
>>>> The best solution would be to make this clock driver a real platform
>>>> driver.
>>>>
>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>> I think it is also a dependence.
>>>
>>> Can you help me understand why it is better to make this driver a platform driver?
>>> Thank you very much!
>>>
>> arch_initcall(customize_machine)
>> -->of_platform_populate
>> -->of_platform_bus_create
>> -->of_amba_device_create
>> -->amba_device_add
>> -->amba_get_enable_pclk
>> The call sequence above shows that the clock of the amba device must be registered before
>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>> the amba device "arm,pl011" uart.
>
> It is a problem, but Tomeu had a fix to support deferred probes here.
> That was part of the on-demand probing series, but maybe it needs to
> be applied separately if we are moving clock drivers to platform
> drivers.
Hi,
Marek Szyprowski has kindly taken those two patches as part of a series of him:
http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski@samsung.com
I think it would be great if you could test them and report.
Thanks,
Tomeu
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-20 6:38 ` Tomeu Vizoso
0 siblings, 0 replies; 103+ messages in thread
From: Tomeu Vizoso @ 2016-01-20 6:38 UTC (permalink / raw)
To: Rob Herring
Cc: xuejiancheng, Michael Turquette, Stephen Boyd, Philipp Zabel,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King - ARM Linux, Kevin Hilman, Arnd Bergmann,
Olof Johansson, Wei Xu, Haojian Zhuang, Zhangfei Gao,
Bintian Wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng
On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>
>> On 2016/1/14 21:16, xuejiancheng wrote:
>>> Hi Mike,
>>>
>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>> Hi Stephen,
>>>>> Thank you very much for your reply.
>>>>>
>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>> index e434854..b6baebf 100644
>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>> @@ -1,3 +1,10 @@
>>>>>>> +config COMMON_CLK_HI3519
>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>
>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>> lose their __init markings.
>>>>>>
>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>
>>>> The best solution would be to make this clock driver a real platform
>>>> driver.
>>>>
>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>> I think it is also a dependence.
>>>
>>> Can you help me understand why it is better to make this driver a platform driver?
>>> Thank you very much!
>>>
>> arch_initcall(customize_machine)
>> -->of_platform_populate
>> -->of_platform_bus_create
>> -->of_amba_device_create
>> -->amba_device_add
>> -->amba_get_enable_pclk
>> The call sequence above shows that the clock of the amba device must be registered before
>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>> the amba device "arm,pl011" uart.
>
> It is a problem, but Tomeu had a fix to support deferred probes here.
> That was part of the on-demand probing series, but maybe it needs to
> be applied separately if we are moving clock drivers to platform
> drivers.
Hi,
Marek Szyprowski has kindly taken those two patches as part of a series of him:
http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski@samsung.com
I think it would be great if you could test them and report.
Thanks,
Tomeu
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-20 6:38 ` Tomeu Vizoso
0 siblings, 0 replies; 103+ messages in thread
From: Tomeu Vizoso @ 2016-01-20 6:38 UTC (permalink / raw)
To: Rob Herring
Cc: xuejiancheng, Michael Turquette, Stephen Boyd, Philipp Zabel,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King - ARM Linux, Kevin Hilman, Arnd Bergmann,
Olof Johansson, Wei Xu, Haojian Zhuang, Zhangfei Gao,
Bintian Wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng, yanghongwei, suwenping, ml.yang,
gaofei, zhangzhenxing, xuejiancheng
On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>
>> On 2016/1/14 21:16, xuejiancheng wrote:
>>> Hi Mike,
>>>
>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>> Hi Stephen,
>>>>> Thank you very much for your reply.
>>>>>
>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>> index e434854..b6baebf 100644
>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>> @@ -1,3 +1,10 @@
>>>>>>> +config COMMON_CLK_HI3519
>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>
>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>> lose their __init markings.
>>>>>>
>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>
>>>> The best solution would be to make this clock driver a real platform
>>>> driver.
>>>>
>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>> I think it is also a dependence.
>>>
>>> Can you help me understand why it is better to make this driver a platform driver?
>>> Thank you very much!
>>>
>> arch_initcall(customize_machine)
>> -->of_platform_populate
>> -->of_platform_bus_create
>> -->of_amba_device_create
>> -->amba_device_add
>> -->amba_get_enable_pclk
>> The call sequence above shows that the clock of the amba device must be registered before
>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>> the amba device "arm,pl011" uart.
>
> It is a problem, but Tomeu had a fix to support deferred probes here.
> That was part of the on-demand probing series, but maybe it needs to
> be applied separately if we are moving clock drivers to platform
> drivers.
Hi,
Marek Szyprowski has kindly taken those two patches as part of a series of him:
http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski@samsung.com
I think it would be great if you could test them and report.
Thanks,
Tomeu
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-20 6:38 ` Tomeu Vizoso
0 siblings, 0 replies; 103+ messages in thread
From: Tomeu Vizoso @ 2016-01-20 6:38 UTC (permalink / raw)
To: linux-arm-kernel
On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>
>> On 2016/1/14 21:16, xuejiancheng wrote:
>>> Hi Mike,
>>>
>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>> Hi Stephen,
>>>>> Thank you very much for your reply.
>>>>>
>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>> index e434854..b6baebf 100644
>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>> @@ -1,3 +1,10 @@
>>>>>>> +config COMMON_CLK_HI3519
>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>
>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>> lose their __init markings.
>>>>>>
>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>
>>>> The best solution would be to make this clock driver a real platform
>>>> driver.
>>>>
>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>> I think it is also a dependence.
>>>
>>> Can you help me understand why it is better to make this driver a platform driver?
>>> Thank you very much!
>>>
>> arch_initcall(customize_machine)
>> -->of_platform_populate
>> -->of_platform_bus_create
>> -->of_amba_device_create
>> -->amba_device_add
>> -->amba_get_enable_pclk
>> The call sequence above shows that the clock of the amba device must be registered before
>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>> the amba device "arm,pl011" uart.
>
> It is a problem, but Tomeu had a fix to support deferred probes here.
> That was part of the on-demand probing series, but maybe it needs to
> be applied separately if we are moving clock drivers to platform
> drivers.
Hi,
Marek Szyprowski has kindly taken those two patches as part of a series of him:
http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski at samsung.com
I think it would be great if you could test them and report.
Thanks,
Tomeu
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-20 6:38 ` Tomeu Vizoso
(?)
(?)
@ 2016-01-22 8:50 ` xuejiancheng
-1 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-22 8:50 UTC (permalink / raw)
To: Tomeu Vizoso, Rob Herring
Cc: Michael Turquette, Stephen Boyd, Philipp Zabel, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King - ARM Linux,
Kevin Hilman, Arnd Bergmann, Olof Johansson, Wei Xu,
Haojian Zhuang, Zhangfei Gao, Bintian Wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On 2016/1/20 14:38, Tomeu Vizoso wrote:
> On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
>> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>>
>>> On 2016/1/14 21:16, xuejiancheng wrote:
>>>> Hi Mike,
>>>>
>>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>>> Hi Stephen,
>>>>>> Thank you very much for your reply.
>>>>>>
>>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>>> index e434854..b6baebf 100644
>>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>>> @@ -1,3 +1,10 @@
>>>>>>>> +config COMMON_CLK_HI3519
>>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>>
>>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>>> lose their __init markings.
>>>>>>>
>>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>>
>>>>> The best solution would be to make this clock driver a real platform
>>>>> driver.
>>>>>
>>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>>> I think it is also a dependence.
>>>>
>>>> Can you help me understand why it is better to make this driver a platform driver?
>>>> Thank you very much!
>>>>
>>> arch_initcall(customize_machine)
>>> -->of_platform_populate
>>> -->of_platform_bus_create
>>> -->of_amba_device_create
>>> -->amba_device_add
>>> -->amba_get_enable_pclk
>>> The call sequence above shows that the clock of the amba device must be registered before
>>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>>> the amba device "arm,pl011" uart.
>>
>> It is a problem, but Tomeu had a fix to support deferred probes here.
>> That was part of the on-demand probing series, but maybe it needs to
>> be applied separately if we are moving clock drivers to platform
>> drivers.
>
> Hi,
>
> Marek Szyprowski has kindly taken those two patches as part of a series of him:
>
> http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski@samsung.com
>
> I think it would be great if you could test them and report.
>
Hi Tomeu,
I have applied the patch "https://lkml.org/lkml/2015/12/23/105" and tested on my hi3519-demb board.
It works even if the apb_pclk is registered later than the amba-pl011 device being registered.
But I think it is a problem if amba_read_periphid() returns -ENOMEM or -ENODEV when apb_pclk is available.
In this condition，amba_match() returns a non zero value which means the driver and device matches
and the amba_probe() will be called, but amba_device->periphid remains as 0. Then amba_lookup() called in
amba_probe() will return a null id pointer.The null pointer will be passed to amba_driver->probe() and
this may cause a segment fault.
Regards,
Jiancheng
> Thanks,
>
> Tomeu
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-22 8:50 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-22 8:50 UTC (permalink / raw)
To: Tomeu Vizoso, Rob Herring
Cc: Michael Turquette, Stephen Boyd, Philipp Zabel, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King - ARM Linux,
Kevin Hilman, Arnd Bergmann, Olof Johansson, Wei Xu,
Haojian Zhuang, Zhangfei Gao, Bintian Wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei
On 2016/1/20 14:38, Tomeu Vizoso wrote:
> On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
>> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>>
>>> On 2016/1/14 21:16, xuejiancheng wrote:
>>>> Hi Mike,
>>>>
>>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>>> Hi Stephen,
>>>>>> Thank you very much for your reply.
>>>>>>
>>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>>> index e434854..b6baebf 100644
>>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>>> @@ -1,3 +1,10 @@
>>>>>>>> +config COMMON_CLK_HI3519
>>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>>
>>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>>> lose their __init markings.
>>>>>>>
>>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>>
>>>>> The best solution would be to make this clock driver a real platform
>>>>> driver.
>>>>>
>>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>>> I think it is also a dependence.
>>>>
>>>> Can you help me understand why it is better to make this driver a platform driver?
>>>> Thank you very much!
>>>>
>>> arch_initcall(customize_machine)
>>> -->of_platform_populate
>>> -->of_platform_bus_create
>>> -->of_amba_device_create
>>> -->amba_device_add
>>> -->amba_get_enable_pclk
>>> The call sequence above shows that the clock of the amba device must be registered before
>>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>>> the amba device "arm,pl011" uart.
>>
>> It is a problem, but Tomeu had a fix to support deferred probes here.
>> That was part of the on-demand probing series, but maybe it needs to
>> be applied separately if we are moving clock drivers to platform
>> drivers.
>
> Hi,
>
> Marek Szyprowski has kindly taken those two patches as part of a series of him:
>
> http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski@samsung.com
>
> I think it would be great if you could test them and report.
>
Hi Tomeu,
I have applied the patch "https://lkml.org/lkml/2015/12/23/105" and tested on my hi3519-demb board.
It works even if the apb_pclk is registered later than the amba-pl011 device being registered.
But I think it is a problem if amba_read_periphid() returns -ENOMEM or -ENODEV when apb_pclk is available.
In this condition，amba_match() returns a non zero value which means the driver and device matches
and the amba_probe() will be called, but amba_device->periphid remains as 0. Then amba_lookup() called in
amba_probe() will return a null id pointer.The null pointer will be passed to amba_driver->probe() and
this may cause a segment fault.
Regards,
Jiancheng
> Thanks,
>
> Tomeu
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-22 8:50 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-22 8:50 UTC (permalink / raw)
To: Tomeu Vizoso, Rob Herring
Cc: Michael Turquette, Stephen Boyd, Philipp Zabel, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King - ARM Linux,
Kevin Hilman, Arnd Bergmann, Olof Johansson, Wei Xu,
Haojian Zhuang, Zhangfei Gao, Bintian Wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On 2016/1/20 14:38, Tomeu Vizoso wrote:
> On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
>> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>>
>>> On 2016/1/14 21:16, xuejiancheng wrote:
>>>> Hi Mike,
>>>>
>>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>>> Hi Stephen,
>>>>>> Thank you very much for your reply.
>>>>>>
>>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>>> index e434854..b6baebf 100644
>>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>>> @@ -1,3 +1,10 @@
>>>>>>>> +config COMMON_CLK_HI3519
>>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>>
>>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>>> lose their __init markings.
>>>>>>>
>>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>>
>>>>> The best solution would be to make this clock driver a real platform
>>>>> driver.
>>>>>
>>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>>> I think it is also a dependence.
>>>>
>>>> Can you help me understand why it is better to make this driver a platform driver?
>>>> Thank you very much!
>>>>
>>> arch_initcall(customize_machine)
>>> -->of_platform_populate
>>> -->of_platform_bus_create
>>> -->of_amba_device_create
>>> -->amba_device_add
>>> -->amba_get_enable_pclk
>>> The call sequence above shows that the clock of the amba device must be registered before
>>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>>> the amba device "arm,pl011" uart.
>>
>> It is a problem, but Tomeu had a fix to support deferred probes here.
>> That was part of the on-demand probing series, but maybe it needs to
>> be applied separately if we are moving clock drivers to platform
>> drivers.
>
> Hi,
>
> Marek Szyprowski has kindly taken those two patches as part of a series of him:
>
> http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski@samsung.com
>
> I think it would be great if you could test them and report.
>
Hi Tomeu,
I have applied the patch "https://lkml.org/lkml/2015/12/23/105" and tested on my hi3519-demb board.
It works even if the apb_pclk is registered later than the amba-pl011 device being registered.
But I think it is a problem if amba_read_periphid() returns -ENOMEM or -ENODEV when apb_pclk is available.
In this condition，amba_match() returns a non zero value which means the driver and device matches
and the amba_probe() will be called, but amba_device->periphid remains as 0. Then amba_lookup() called in
amba_probe() will return a null id pointer.The null pointer will be passed to amba_driver->probe() and
this may cause a segment fault.
Regards,
Jiancheng
> Thanks,
>
> Tomeu
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-22 8:50 ` xuejiancheng
0 siblings, 0 replies; 103+ messages in thread
From: xuejiancheng @ 2016-01-22 8:50 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/20 14:38, Tomeu Vizoso wrote:
> On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
>> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>>
>>> On 2016/1/14 21:16, xuejiancheng wrote:
>>>> Hi Mike,
>>>>
>>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>>> Hi Stephen,
>>>>>> Thank you very much for your reply.
>>>>>>
>>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>>> index e434854..b6baebf 100644
>>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>>> @@ -1,3 +1,10 @@
>>>>>>>> +config COMMON_CLK_HI3519
>>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>>
>>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>>> lose their __init markings.
>>>>>>>
>>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>>
>>>>> The best solution would be to make this clock driver a real platform
>>>>> driver.
>>>>>
>>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>>> I think it is also a dependence.
>>>>
>>>> Can you help me understand why it is better to make this driver a platform driver?
>>>> Thank you very much!
>>>>
>>> arch_initcall(customize_machine)
>>> -->of_platform_populate
>>> -->of_platform_bus_create
>>> -->of_amba_device_create
>>> -->amba_device_add
>>> -->amba_get_enable_pclk
>>> The call sequence above shows that the clock of the amba device must be registered before
>>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>>> the amba device "arm,pl011" uart.
>>
>> It is a problem, but Tomeu had a fix to support deferred probes here.
>> That was part of the on-demand probing series, but maybe it needs to
>> be applied separately if we are moving clock drivers to platform
>> drivers.
>
> Hi,
>
> Marek Szyprowski has kindly taken those two patches as part of a series of him:
>
> http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski at samsung.com
>
> I think it would be great if you could test them and report.
>
Hi Tomeu,
I have applied the patch "https://lkml.org/lkml/2015/12/23/105" and tested on my hi3519-demb board.
It works even if the apb_pclk is registered later than the amba-pl011 device being registered.
But I think it is a problem if amba_read_periphid() returns -ENOMEM or -ENODEV when apb_pclk is available.
In this condition?amba_match() returns a non zero value which means the driver and device matches
and the amba_probe() will be called, but amba_device->periphid remains as 0. Then amba_lookup() called in
amba_probe() will return a null id pointer.The null pointer will be passed to amba_driver->probe() and
this may cause a segment fault.
Regards,
Jiancheng
> Thanks,
>
> Tomeu
>
> .
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
2016-01-22 8:50 ` xuejiancheng
(?)
(?)
@ 2016-01-22 9:55 ` Tomeu Vizoso
-1 siblings, 0 replies; 103+ messages in thread
From: Tomeu Vizoso @ 2016-01-22 9:55 UTC (permalink / raw)
To: xuejiancheng
Cc: Rob Herring, Michael Turquette, Stephen Boyd, Philipp Zabel,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King - ARM Linux, Kevin Hilman, Arnd Bergmann,
Olof Johansson, Wei Xu, Haojian Zhuang, Zhangfei Gao,
Bintian Wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng, yanghongwei, suwenping, ml.yang,
gaofei, zhangzhenxing, xuejiancheng, Marek Szyprowski
On 22 January 2016 at 09:50, xuejiancheng <xuejiancheng@huawei.com> wrote:
> On 2016/1/20 14:38, Tomeu Vizoso wrote:
>> On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
>>> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>>>
>>>> On 2016/1/14 21:16, xuejiancheng wrote:
>>>>> Hi Mike,
>>>>>
>>>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>>>> Hi Stephen,
>>>>>>> Thank you very much for your reply.
>>>>>>>
>>>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>>>> index e434854..b6baebf 100644
>>>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>>>> @@ -1,3 +1,10 @@
>>>>>>>>> +config COMMON_CLK_HI3519
>>>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>>>
>>>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>>>> lose their __init markings.
>>>>>>>>
>>>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>>>
>>>>>> The best solution would be to make this clock driver a real platform
>>>>>> driver.
>>>>>>
>>>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>>>> I think it is also a dependence.
>>>>>
>>>>> Can you help me understand why it is better to make this driver a platform driver?
>>>>> Thank you very much!
>>>>>
>>>> arch_initcall(customize_machine)
>>>> -->of_platform_populate
>>>> -->of_platform_bus_create
>>>> -->of_amba_device_create
>>>> -->amba_device_add
>>>> -->amba_get_enable_pclk
>>>> The call sequence above shows that the clock of the amba device must be registered before
>>>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>>>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>>>> the amba device "arm,pl011" uart.
>>>
>>> It is a problem, but Tomeu had a fix to support deferred probes here.
>>> That was part of the on-demand probing series, but maybe it needs to
>>> be applied separately if we are moving clock drivers to platform
>>> drivers.
>>
>> Hi,
>>
>> Marek Szyprowski has kindly taken those two patches as part of a series of him:
>>
>> http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski@samsung.com
>>
>> I think it would be great if you could test them and report.
>>
> Hi Tomeu,
>
> I have applied the patch "https://lkml.org/lkml/2015/12/23/105" and tested on my hi3519-demb board.
> It works even if the apb_pclk is registered later than the amba-pl011 device being registered.
>
> But I think it is a problem if amba_read_periphid() returns -ENOMEM or -ENODEV when apb_pclk is available.
> In this condition，amba_match() returns a non zero value which means the driver and device matches
> and the amba_probe() will be called, but amba_device->periphid remains as 0. Then amba_lookup() called in
> amba_probe() will return a null id pointer.The null pointer will be passed to amba_driver->probe() and
> this may cause a segment fault.
But, have you applied the other patches in the series? There's one
that should handle the other error codes.
In any case, any feedback you have on that series should be given in
the other thread.
Regards,
Tomeu
> Regards,
>
> Jiancheng
>
>> Thanks,
>>
>> Tomeu
>>
>> .
>>
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-22 9:55 ` Tomeu Vizoso
0 siblings, 0 replies; 103+ messages in thread
From: Tomeu Vizoso @ 2016-01-22 9:55 UTC (permalink / raw)
To: xuejiancheng
Cc: Rob Herring, Michael Turquette, Stephen Boyd, Philipp Zabel,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King - ARM Linux, Kevin Hilman, Arnd Bergmann,
Olof Johansson, Wei Xu, Haojian Zhuang, Zhangfei Gao,
Bintian Wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng
On 22 January 2016 at 09:50, xuejiancheng <xuejiancheng@huawei.com> wrote:
> On 2016/1/20 14:38, Tomeu Vizoso wrote:
>> On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
>>> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>>>
>>>> On 2016/1/14 21:16, xuejiancheng wrote:
>>>>> Hi Mike,
>>>>>
>>>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>>>> Hi Stephen,
>>>>>>> Thank you very much for your reply.
>>>>>>>
>>>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>>>> index e434854..b6baebf 100644
>>>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>>>> @@ -1,3 +1,10 @@
>>>>>>>>> +config COMMON_CLK_HI3519
>>>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>>>
>>>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>>>> lose their __init markings.
>>>>>>>>
>>>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>>>
>>>>>> The best solution would be to make this clock driver a real platform
>>>>>> driver.
>>>>>>
>>>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>>>> I think it is also a dependence.
>>>>>
>>>>> Can you help me understand why it is better to make this driver a platform driver?
>>>>> Thank you very much!
>>>>>
>>>> arch_initcall(customize_machine)
>>>> -->of_platform_populate
>>>> -->of_platform_bus_create
>>>> -->of_amba_device_create
>>>> -->amba_device_add
>>>> -->amba_get_enable_pclk
>>>> The call sequence above shows that the clock of the amba device must be registered before
>>>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>>>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>>>> the amba device "arm,pl011" uart.
>>>
>>> It is a problem, but Tomeu had a fix to support deferred probes here.
>>> That was part of the on-demand probing series, but maybe it needs to
>>> be applied separately if we are moving clock drivers to platform
>>> drivers.
>>
>> Hi,
>>
>> Marek Szyprowski has kindly taken those two patches as part of a series of him:
>>
>> http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski@samsung.com
>>
>> I think it would be great if you could test them and report.
>>
> Hi Tomeu,
>
> I have applied the patch "https://lkml.org/lkml/2015/12/23/105" and tested on my hi3519-demb board.
> It works even if the apb_pclk is registered later than the amba-pl011 device being registered.
>
> But I think it is a problem if amba_read_periphid() returns -ENOMEM or -ENODEV when apb_pclk is available.
> In this condition，amba_match() returns a non zero value which means the driver and device matches
> and the amba_probe() will be called, but amba_device->periphid remains as 0. Then amba_lookup() called in
> amba_probe() will return a null id pointer.The null pointer will be passed to amba_driver->probe() and
> this may cause a segment fault.
But, have you applied the other patches in the series? There's one
that should handle the other error codes.
In any case, any feedback you have on that series should be given in
the other thread.
Regards,
Tomeu
> Regards,
>
> Jiancheng
>
>> Thanks,
>>
>> Tomeu
>>
>> .
>>
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-22 9:55 ` Tomeu Vizoso
0 siblings, 0 replies; 103+ messages in thread
From: Tomeu Vizoso @ 2016-01-22 9:55 UTC (permalink / raw)
To: xuejiancheng
Cc: Rob Herring, Michael Turquette, Stephen Boyd, Philipp Zabel,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King - ARM Linux, Kevin Hilman, Arnd Bergmann,
Olof Johansson, Wei Xu, Haojian Zhuang, Zhangfei Gao,
Bintian Wang, linux-kernel, linux-clk, devicetree,
linux-arm-kernel, yanhaifeng, yanghongwei, suwenping, ml.yang,
gaofei, zhangzhenxing, xuejiancheng, Marek Szyprowski
On 22 January 2016 at 09:50, xuejiancheng <xuejiancheng@huawei.com> wrote:
> On 2016/1/20 14:38, Tomeu Vizoso wrote:
>> On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
>>> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com>=
wrote:
>>>>
>>>> On 2016/1/14 21:16, xuejiancheng wrote:
>>>>> Hi Mike,
>>>>>
>>>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>>>> Hi Stephen,
>>>>>>> Thank you very much for your reply.
>>>>>>>
>>>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilico=
n/Kconfig
>>>>>>>>> index e434854..b6baebf 100644
>>>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>>>> @@ -1,3 +1,10 @@
>>>>>>>>> +config COMMON_CLK_HI3519
>>>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>>>
>>>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>>>> lose their __init markings.
>>>>>>>>
>>>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>>>
>>>>>> The best solution would be to make this clock driver a real platform
>>>>>> driver.
>>>>>>
>>>>> Now the work clock of the clocksource timer-sp804 is provided by this=
driver. So
>>>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock =
is treated
>>>>> as a fixed-clock provider, this driver can be implemented as a platfo=
rm driver.
>>>>> Then the crg device must be registered before other clock consumer de=
vices.Accordingly
>>>>> the crg device node must be written above all other clock consumer de=
vices node in dts files.
>>>>> I think it is also a dependence.
>>>>>
>>>>> Can you help me understand why it is better to make this driver a pla=
tform driver?
>>>>> Thank you very much!
>>>>>
>>>> arch_initcall(customize_machine)
>>>> -->of_platform_populate
>>>> -->of_platform_bus_create
>>>> -->of_amba_device_create
>>>> -->amba_device_add
>>>> -->amba_get_enable_pclk
>>>> The call sequence above shows that the clock of the amba device must b=
e registered before
>>>> amba_device_add. The clock of "arm,pl011" uart is registered in the pr=
obe function of the
>>>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must=
be created before
>>>> the amba device "arm,pl011" uart.
>>>
>>> It is a problem, but Tomeu had a fix to support deferred probes here.
>>> That was part of the on-demand probing series, but maybe it needs to
>>> be applied separately if we are moving clock drivers to platform
>>> drivers.
>>
>> Hi,
>>
>> Marek Szyprowski has kindly taken those two patches as part of a series =
of him:
>>
>> http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski@s=
amsung.com
>>
>> I think it would be great if you could test them and report.
>>
> Hi Tomeu,
>
> I have applied the patch "https://lkml.org/lkml/2015/12/23/105" and teste=
d on my hi3519-demb board.
> It works even if the apb_pclk is registered later than the amba-pl011 dev=
ice being registered.
>
> But I think it is a problem if amba_read_periphid() returns -ENOMEM or -E=
NODEV when apb_pclk is available.
> In this condition=EF=BC=8Camba_match() returns a non zero value which mea=
ns the driver and device matches
> and the amba_probe() will be called, but amba_device->periphid remains as=
0. Then amba_lookup() called in
> amba_probe() will return a null id pointer.The null pointer will be passe=
d to amba_driver->probe() and
> this may cause a segment fault.
But, have you applied the other patches in the series? There's one
that should handle the other error codes.
In any case, any feedback you have on that series should be given in
the other thread.
Regards,
Tomeu
> Regards,
>
> Jiancheng
>
>> Thanks,
>>
>> Tomeu
>>
>> .
>>
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc
@ 2016-01-22 9:55 ` Tomeu Vizoso
0 siblings, 0 replies; 103+ messages in thread
From: Tomeu Vizoso @ 2016-01-22 9:55 UTC (permalink / raw)
To: linux-arm-kernel
On 22 January 2016 at 09:50, xuejiancheng <xuejiancheng@huawei.com> wrote:
> On 2016/1/20 14:38, Tomeu Vizoso wrote:
>> On 19 January 2016 at 19:20, Rob Herring <robh+dt@kernel.org> wrote:
>>> On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@huawei.com> wrote:
>>>>
>>>> On 2016/1/14 21:16, xuejiancheng wrote:
>>>>> Hi Mike,
>>>>>
>>>>> On 2016/1/14 2:57, Michael Turquette wrote:
>>>>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>>>>> Hi Stephen,
>>>>>>> Thank you very much for your reply.
>>>>>>>
>>>>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>>>>> index e434854..b6baebf 100644
>>>>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>>>>> @@ -1,3 +1,10 @@
>>>>>>>>> +config COMMON_CLK_HI3519
>>>>>>>>> + tristate "Clock Driver for Hi3519"
>>>>>>>>
>>>>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>>>>> lose their __init markings.
>>>>>>>>
>>>>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>>>>
>>>>>> The best solution would be to make this clock driver a real platform
>>>>>> driver.
>>>>>>
>>>>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>>>>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>>>>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>>>>> Then the crg device must be registered before other clock consumer devices.Accordingly
>>>>> the crg device node must be written above all other clock consumer devices node in dts files.
>>>>> I think it is also a dependence.
>>>>>
>>>>> Can you help me understand why it is better to make this driver a platform driver?
>>>>> Thank you very much!
>>>>>
>>>> arch_initcall(customize_machine)
>>>> -->of_platform_populate
>>>> -->of_platform_bus_create
>>>> -->of_amba_device_create
>>>> -->amba_device_add
>>>> -->amba_get_enable_pclk
>>>> The call sequence above shows that the clock of the amba device must be registered before
>>>> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
>>>> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
>>>> the amba device "arm,pl011" uart.
>>>
>>> It is a problem, but Tomeu had a fix to support deferred probes here.
>>> That was part of the on-demand probing series, but maybe it needs to
>>> be applied separately if we are moving clock drivers to platform
>>> drivers.
>>
>> Hi,
>>
>> Marek Szyprowski has kindly taken those two patches as part of a series of him:
>>
>> http://lkml.kernel.org/g/1450868368-5650-1-git-send-email-m.szyprowski at samsung.com
>>
>> I think it would be great if you could test them and report.
>>
> Hi Tomeu,
>
> I have applied the patch "https://lkml.org/lkml/2015/12/23/105" and tested on my hi3519-demb board.
> It works even if the apb_pclk is registered later than the amba-pl011 device being registered.
>
> But I think it is a problem if amba_read_periphid() returns -ENOMEM or -ENODEV when apb_pclk is available.
> In this condition?amba_match() returns a non zero value which means the driver and device matches
> and the amba_probe() will be called, but amba_device->periphid remains as 0. Then amba_lookup() called in
> amba_probe() will return a null id pointer.The null pointer will be passed to amba_driver->probe() and
> this may cause a segment fault.
But, have you applied the other patches in the series? There's one
that should handle the other error codes.
In any case, any feedback you have on that series should be given in
the other thread.
Regards,
Tomeu
> Regards,
>
> Jiancheng
>
>> Thanks,
>>
>> Tomeu
>>
>> .
>>
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-12 22:51 ` Arnd Bergmann
@ 2016-01-25 14:26 ` Lee Jones
-1 siblings, 0 replies; 103+ messages in thread
From: Lee Jones @ 2016-01-25 14:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: xuejiancheng, mturquette, sboyd, p.zabel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, khilman, olof,
xuwei5, haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Tue, 12 Jan 2016, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote:
> > >>>>>
> > >>>> Not yet.
> > >>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
> > >>>> with the SOC name. This binding is just used for describing the compatible string now.
> > >>>> When more functions on hi3519 SOC are added later, the specific driver will be also
> > >>>> needed.
> > >>>
> > >>> Save this binding until it has more functionality. We here "I'll add
> > >>> to this later" all too often.
> > >>>
> > >>
> > >> In the hi3519.dtsi file, there is a system-controller device node described like below:
> > >> sysctrl: system-controller@12010000 {
> > >> compatible = "hisilicon,hi3519-sysctrl", "syscon";
> > >> reg = <0x12010000 0x1000>;
> > >> };
> > >> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
> > >> compatible string?
> > >
> > > Where is this compatible string _used_?
> > >
> > >> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
> > >> Could you give some suggestions? Thank you very much!
> > >
> > > If you're not using the compatible i.e. the device doesn't have its
> > > own driver yet, then there is no need to supply the binding at all, is
> > > there?
> > >
> >
> > OK. Thank you.
> >
>
> Sorry for stepping in late here. I still think that every syscon device should
> come with a specific compatible string, so we have the option of creating a
> driver later on, and I'd like to see a binding document that lists those strings
> (which I believe exists here).
>
> It's really hard to add compatible strings later on, anything else we can
> work around by keying off that string and adding a workaround in the kernel.
Why is it more difficult (or any different) to add a compatible string
later (when it is used) over now (when it is not used)?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-25 14:26 ` Lee Jones
0 siblings, 0 replies; 103+ messages in thread
From: Lee Jones @ 2016-01-25 14:26 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 12 Jan 2016, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote:
> > >>>>>
> > >>>> Not yet.
> > >>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
> > >>>> with the SOC name. This binding is just used for describing the compatible string now.
> > >>>> When more functions on hi3519 SOC are added later, the specific driver will be also
> > >>>> needed.
> > >>>
> > >>> Save this binding until it has more functionality. We here "I'll add
> > >>> to this later" all too often.
> > >>>
> > >>
> > >> In the hi3519.dtsi file, there is a system-controller device node described like below:
> > >> sysctrl: system-controller at 12010000 {
> > >> compatible = "hisilicon,hi3519-sysctrl", "syscon";
> > >> reg = <0x12010000 0x1000>;
> > >> };
> > >> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
> > >> compatible string??
> > >
> > > Where is this compatible string _used_?
> > >
> > >> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
> > >> Could you give some suggestions? Thank you very much!
> > >
> > > If you're not using the compatible i.e. the device doesn't have its
> > > own driver yet, then there is no need to supply the binding at all, is
> > > there?
> > >
> >
> > OK. Thank you.
> >
>
> Sorry for stepping in late here. I still think that every syscon device should
> come with a specific compatible string, so we have the option of creating a
> driver later on, and I'd like to see a binding document that lists those strings
> (which I believe exists here).
>
> It's really hard to add compatible strings later on, anything else we can
> work around by keying off that string and adding a workaround in the kernel.
Why is it more difficult (or any different) to add a compatible string
later (when it is used) over now (when it is not used)?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
2016-01-25 14:26 ` Lee Jones
@ 2016-01-25 14:45 ` Arnd Bergmann
-1 siblings, 0 replies; 103+ messages in thread
From: Arnd Bergmann @ 2016-01-25 14:45 UTC (permalink / raw)
To: Lee Jones
Cc: xuejiancheng, mturquette, sboyd, p.zabel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, khilman, olof,
xuwei5, haojian.zhuang, zhangfei.gao, bintian.wang, linux-kernel,
linux-clk, devicetree, linux-arm-kernel, yanhaifeng, yanghongwei,
suwenping, ml.yang, gaofei, zhangzhenxing, xuejiancheng
On Monday 25 January 2016 14:26:09 Lee Jones wrote:
> On Tue, 12 Jan 2016, Arnd Bergmann wrote:
>
> > On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote:
> > > >>>>>
> > > >>>> Not yet.
> > > >>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
> > > >>>> with the SOC name. This binding is just used for describing the compatible string now.
> > > >>>> When more functions on hi3519 SOC are added later, the specific driver will be also
> > > >>>> needed.
> > > >>>
> > > >>> Save this binding until it has more functionality. We here "I'll add
> > > >>> to this later" all too often.
> > > >>>
> > > >>
> > > >> In the hi3519.dtsi file, there is a system-controller device node described like below:
> > > >> sysctrl: system-controller@12010000 {
> > > >> compatible = "hisilicon,hi3519-sysctrl", "syscon";
> > > >> reg = <0x12010000 0x1000>;
> > > >> };
> > > >> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
> > > >> compatible string?
> > > >
> > > > Where is this compatible string _used_?
> > > >
> > > >> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
> > > >> Could you give some suggestions? Thank you very much!
> > > >
> > > > If you're not using the compatible i.e. the device doesn't have its
> > > > own driver yet, then there is no need to supply the binding at all, is
> > > > there?
> > > >
> > >
> > > OK. Thank you.
> > >
> >
> > Sorry for stepping in late here. I still think that every syscon device should
> > come with a specific compatible string, so we have the option of creating a
> > driver later on, and I'd like to see a binding document that lists those strings
> > (which I believe exists here).
> >
> > It's really hard to add compatible strings later on, anything else we can
> > work around by keying off that string and adding a workaround in the kernel.
>
> Why is it more difficult (or any different) to add a compatible string
> later (when it is used) over now (when it is not used)?
There are many reasons why it can be hard to change a DT binary or source
file later on. Sometimes the dtb is shipped with the firmware, sometimes
someone has a slightly different platform that is not yet upstreamed,
and they need to know about the change when forward-porting to a newer
kernel.
Either way, you always want to be able to run a newer kernel on an older
dtb file without loss of functionality, so all "compatible" strings should
generally be as specific as possible (with fallbacks to more generic
strings). We do this even for devices that we think are identical, e.g.
when multiple SoC vendors integrate the same IP block, but in this case,
we already *know* that they are incompatible, so we should never have
the same string as the most specific ID.
Arnd
^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl
@ 2016-01-25 14:45 ` Arnd Bergmann
0 siblings, 0 replies; 103+ messages in thread
From: Arnd Bergmann @ 2016-01-25 14:45 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 January 2016 14:26:09 Lee Jones wrote:
> On Tue, 12 Jan 2016, Arnd Bergmann wrote:
>
> > On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote:
> > > >>>>>
> > > >>>> Not yet.
> > > >>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string
> > > >>>> with the SOC name. This binding is just used for describing the compatible string now.
> > > >>>> When more functions on hi3519 SOC are added later, the specific driver will be also
> > > >>>> needed.
> > > >>>
> > > >>> Save this binding until it has more functionality. We here "I'll add
> > > >>> to this later" all too often.
> > > >>>
> > > >>
> > > >> In the hi3519.dtsi file, there is a system-controller device node described like below:
> > > >> sysctrl: system-controller at 12010000 {
> > > >> compatible = "hisilicon,hi3519-sysctrl", "syscon";
> > > >> reg = <0x12010000 0x1000>;
> > > >> };
> > > >> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the
> > > >> compatible string??
> > > >
> > > > Where is this compatible string _used_?
> > > >
> > > >> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding?
> > > >> Could you give some suggestions? Thank you very much!
> > > >
> > > > If you're not using the compatible i.e. the device doesn't have its
> > > > own driver yet, then there is no need to supply the binding at all, is
> > > > there?
> > > >
> > >
> > > OK. Thank you.
> > >
> >
> > Sorry for stepping in late here. I still think that every syscon device should
> > come with a specific compatible string, so we have the option of creating a
> > driver later on, and I'd like to see a binding document that lists those strings
> > (which I believe exists here).
> >
> > It's really hard to add compatible strings later on, anything else we can
> > work around by keying off that string and adding a workaround in the kernel.
>
> Why is it more difficult (or any different) to add a compatible string
> later (when it is used) over now (when it is not used)?
There are many reasons why it can be hard to change a DT binary or source
file later on. Sometimes the dtb is shipped with the firmware, sometimes
someone has a slightly different platform that is not yet upstreamed,
and they need to know about the change when forward-porting to a newer
kernel.
Either way, you always want to be able to run a newer kernel on an older
dtb file without loss of functionality, so all "compatible" strings should
generally be as specific as possible (with fallbacks to more generic
strings). We do this even for devices that we think are identical, e.g.
when multiple SoC vendors integrate the same IP block, but in this case,
we already *know* that they are incompatible, so we should never have
the same string as the most specific ID.
Arnd
^ permalink raw reply [flat|nested] 103+ messages in thread
end of thread, other threads:[~2016-01-25 14:47 UTC | newest]
Thread overview: 103+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-08 2:16 [PATCH v5 0/6] ARM: hisi: Add initial support including clock driver for Hi3519 soc Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 2:16 ` [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-09 6:24 ` kbuild test robot
2016-01-09 6:24 ` kbuild test robot
2016-01-09 6:24 ` kbuild test robot
2016-01-09 15:33 ` Rob Herring
2016-01-09 15:33 ` Rob Herring
2016-01-11 3:47 ` xuejiancheng
2016-01-11 3:47 ` xuejiancheng
2016-01-11 3:47 ` xuejiancheng
2016-01-12 22:12 ` Stephen Boyd
2016-01-12 22:12 ` Stephen Boyd
2016-01-13 3:03 ` xuejiancheng
2016-01-13 3:03 ` xuejiancheng
2016-01-13 3:03 ` xuejiancheng
2016-01-13 18:57 ` Michael Turquette
2016-01-13 18:57 ` Michael Turquette
2016-01-13 18:57 ` Michael Turquette
2016-01-14 13:16 ` xuejiancheng
2016-01-14 13:16 ` xuejiancheng
2016-01-14 13:16 ` xuejiancheng
2016-01-15 7:57 ` xuejiancheng
2016-01-15 7:57 ` xuejiancheng
2016-01-15 7:57 ` xuejiancheng
2016-01-19 18:20 ` Rob Herring
2016-01-19 18:20 ` Rob Herring
2016-01-19 18:20 ` Rob Herring
2016-01-19 18:20 ` Rob Herring
2016-01-20 6:38 ` Tomeu Vizoso
2016-01-20 6:38 ` Tomeu Vizoso
2016-01-20 6:38 ` Tomeu Vizoso
2016-01-20 6:38 ` Tomeu Vizoso
2016-01-22 8:50 ` xuejiancheng
2016-01-22 8:50 ` xuejiancheng
2016-01-22 8:50 ` xuejiancheng
2016-01-22 8:50 ` xuejiancheng
2016-01-22 9:55 ` Tomeu Vizoso
2016-01-22 9:55 ` Tomeu Vizoso
2016-01-22 9:55 ` Tomeu Vizoso
2016-01-22 9:55 ` Tomeu Vizoso
2016-01-08 2:16 ` [PATCH v5 2/6] ARM: hisi: add compatible string for Hi3519 soc Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 2:16 ` [PATCH v5 3/6] ARM: config: hisi: enable CONFIG_RESET_CONTROLLER Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 2:16 ` [PATCH v5 4/6] ARM: debug: add hi3519 debug uart Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 15:08 ` Russell King - ARM Linux
2016-01-08 15:08 ` Russell King - ARM Linux
2016-01-11 2:32 ` xuejiancheng
2016-01-11 2:32 ` xuejiancheng
2016-01-11 2:32 ` xuejiancheng
2016-01-08 2:16 ` [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 21:04 ` Rob Herring
2016-01-08 21:04 ` Rob Herring
2016-01-11 5:48 ` Lee Jones
2016-01-11 5:48 ` Lee Jones
2016-01-11 7:50 ` xuejiancheng
2016-01-11 7:50 ` xuejiancheng
2016-01-11 7:50 ` xuejiancheng
2016-01-11 8:55 ` Lee Jones
2016-01-11 8:55 ` Lee Jones
2016-01-12 1:35 ` xuejiancheng
2016-01-12 1:35 ` xuejiancheng
2016-01-12 1:35 ` xuejiancheng
2016-01-12 7:41 ` Lee Jones
2016-01-12 7:41 ` Lee Jones
2016-01-12 8:17 ` xuejiancheng
2016-01-12 8:17 ` xuejiancheng
2016-01-12 8:17 ` xuejiancheng
2016-01-12 8:39 ` Lee Jones
2016-01-12 8:39 ` Lee Jones
2016-01-12 9:28 ` xuejiancheng
2016-01-12 9:28 ` xuejiancheng
2016-01-12 9:28 ` xuejiancheng
2016-01-12 22:51 ` Arnd Bergmann
2016-01-12 22:51 ` Arnd Bergmann
2016-01-13 9:08 ` xuejiancheng
2016-01-13 9:08 ` xuejiancheng
2016-01-13 9:08 ` xuejiancheng
2016-01-13 10:00 ` Arnd Bergmann
2016-01-13 10:00 ` Arnd Bergmann
2016-01-25 14:26 ` Lee Jones
2016-01-25 14:26 ` Lee Jones
2016-01-25 14:45 ` Arnd Bergmann
2016-01-25 14:45 ` Arnd Bergmann
2016-01-08 2:16 ` [PATCH v5 6/6] ARM: dts: add dts files for Hi3519 Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 2:16 ` Jiancheng Xue
2016-01-08 15:10 ` Russell King - ARM Linux
2016-01-08 15:10 ` Russell King - ARM Linux
2016-01-08 15:10 ` Russell King - ARM Linux
2016-01-11 2:05 ` xuejiancheng
2016-01-11 2:05 ` xuejiancheng
2016-01-11 2:05 ` xuejiancheng
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.