* [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC
@ 2014-02-05 5:16 Rahul Sharma
2014-02-05 5:16 ` [PATCH V2 1/3] ARM: EXYNOS: initial board " Rahul Sharma
` (3 more replies)
0 siblings, 4 replies; 20+ messages in thread
From: Rahul Sharma @ 2014-02-05 5:16 UTC (permalink / raw)
To: linux-samsung-soc; +Cc: kgene.kim, tomasz.figa, joshi, r.sh.open, Rahul Sharma
This is re-spin of V2 which add arch-side support for exynos5260 SoC.
V2:
1) Split up DT patch into SoC and Board patch.
This series is based on Kukjin's for-next branch at
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git
Pankaj Dubey (1):
ARM: EXYNOS: initial board support for exynos5260 SoC
Rahul Sharma (2):
ARM: dts: add dts files for exynos5260 SoC
ARM: dts: add dts files for xyref5260 board
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572 +++++++++++++++++++++++
arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts | 105 +++++
arch/arm/boot/dts/exynos5260.dtsi | 317 +++++++++++++
arch/arm/mach-exynos/Kconfig | 9 +
arch/arm/mach-exynos/common.c | 18 +
arch/arm/mach-exynos/include/mach/map.h | 1 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 1 +
arch/arm/plat-samsung/include/plat/cpu.h | 8 +
arch/arm/plat-samsung/include/plat/map-s5p.h | 1 +
10 files changed, 1033 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
mode change 100644 => 100755 arch/arm/mach-exynos/include/mach/map.h
mode change 100644 => 100755 arch/arm/mach-exynos/mach-exynos5-dt.c
mode change 100644 => 100755 arch/arm/plat-samsung/include/plat/cpu.h
--
1.7.9.5
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH V2 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC
2014-02-05 5:16 [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC Rahul Sharma
@ 2014-02-05 5:16 ` Rahul Sharma
2014-02-05 21:55 ` Olof Johansson
2014-02-05 5:16 ` [PATCH V2 2/3] ARM: dts: add dts files " Rahul Sharma
` (2 subsequent siblings)
3 siblings, 1 reply; 20+ messages in thread
From: Rahul Sharma @ 2014-02-05 5:16 UTC (permalink / raw)
To: linux-samsung-soc
Cc: kgene.kim, tomasz.figa, joshi, r.sh.open, Pankaj Dubey, Rahul Sharma
From: Pankaj Dubey <pankaj.dubey@samsung.com>
This patch add basic arch side support for exynos5260 SoC.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
---
arch/arm/mach-exynos/Kconfig | 9 +++++++++
arch/arm/mach-exynos/common.c | 18 ++++++++++++++++++
arch/arm/mach-exynos/include/mach/map.h | 1 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 1 +
arch/arm/plat-samsung/include/plat/cpu.h | 8 ++++++++
arch/arm/plat-samsung/include/plat/map-s5p.h | 1 +
6 files changed, 38 insertions(+)
mode change 100644 => 100755 arch/arm/mach-exynos/include/mach/map.h
mode change 100644 => 100755 arch/arm/mach-exynos/mach-exynos5-dt.c
mode change 100644 => 100755 arch/arm/plat-samsung/include/plat/cpu.h
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 4c414af..5c96248 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -91,6 +91,15 @@ config SOC_EXYNOS5250
help
Enable EXYNOS5250 SoC support
+config SOC_EXYNOS5260
+ bool "SAMSUNG EXYNOS5260"
+ default y
+ depends on ARCH_EXYNOS5
+ select AUTO_ZRELADDR
+ select SAMSUNG_DMADEV
+ help
+ Enable EXYNOS5260 SoC support
+
config SOC_EXYNOS5420
bool "SAMSUNG EXYNOS5420"
default y
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 72ae5d3..4ee14ed 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -52,6 +52,7 @@ static const char name_exynos4210[] = "EXYNOS4210";
static const char name_exynos4212[] = "EXYNOS4212";
static const char name_exynos4412[] = "EXYNOS4412";
static const char name_exynos5250[] = "EXYNOS5250";
+static const char name_exynos5260[] = "EXYNOS5260";
static const char name_exynos5420[] = "EXYNOS5420";
static const char name_exynos5440[] = "EXYNOS5440";
@@ -85,6 +86,12 @@ static struct cpu_table cpu_ids[] __initdata = {
.init = exynos_init,
.name = name_exynos5250,
}, {
+ .idcode = EXYNOS5260_SOC_ID,
+ .idmask = EXYNOS5_SOC_MASK,
+ .map_io = exynos5_map_io,
+ .init = exynos_init,
+ .name = name_exynos5260,
+ }, {
.idcode = EXYNOS5420_SOC_ID,
.idmask = EXYNOS5_SOC_MASK,
.map_io = exynos5_map_io,
@@ -263,6 +270,15 @@ static struct map_desc exynos5_iodesc[] __initdata = {
},
};
+static struct map_desc exynos5260_iodesc[] __initdata = {
+ {
+ .virtual = (unsigned long)S5P_VA_SYSRAM_NS,
+ .pfn = __phys_to_pfn(EXYNOS5260_PA_SYSRAM_NS),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ },
+};
+
void exynos4_restart(enum reboot_mode mode, const char *cmd)
{
__raw_writel(0x1, S5P_SWRESET);
@@ -374,6 +390,8 @@ static void __init exynos5_map_io(void)
if (soc_is_exynos5250())
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
+ if (soc_is_exynos5260())
+ iotable_init(exynos5260_iodesc, ARRAY_SIZE(exynos5260_iodesc));
}
struct bus_type exynos_subsys = {
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
old mode 100644
new mode 100755
index 7b046b5..bd6fa02
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -29,6 +29,7 @@
#define EXYNOS4210_PA_SYSRAM_NS 0x0203F000
#define EXYNOS4x12_PA_SYSRAM_NS 0x0204F000
#define EXYNOS5250_PA_SYSRAM_NS 0x0204F000
+#define EXYNOS5260_PA_SYSRAM_NS 0x02073000
#define EXYNOS_PA_CHIPID 0x10000000
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
old mode 100644
new mode 100755
index 65a4646..18aee57
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -50,6 +50,7 @@ static void __init exynos5_dt_machine_init(void)
static char const *exynos5_dt_compat[] __initdata = {
"samsung,exynos5250",
+ "samsung,exynos5260",
"samsung,exynos5420",
"samsung,exynos5440",
NULL
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h b/arch/arm/plat-samsung/include/plat/cpu.h
old mode 100644
new mode 100755
index 335beb3..60687aa
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -46,6 +46,7 @@ extern unsigned long samsung_cpu_id;
#define EXYNOS4_CPU_MASK 0xFFFE0000
#define EXYNOS5250_SOC_ID 0x43520000
+#define EXYNOS5260_SOC_ID 0xE5260000
#define EXYNOS5420_SOC_ID 0xE5420000
#define EXYNOS5440_SOC_ID 0xE5440000
#define EXYNOS5_SOC_MASK 0xFFFFF000
@@ -68,6 +69,7 @@ IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
+IS_SAMSUNG_CPU(exynos5260, EXYNOS5260_SOC_ID, EXYNOS5_SOC_MASK)
IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
@@ -148,6 +150,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
# define soc_is_exynos5250() 0
#endif
+#if defined(CONFIG_SOC_EXYNOS5260)
+# define soc_is_exynos5260() is_samsung_exynos5260()
+#else
+# define soc_is_exynos5260() 0
+#endif
+
#if defined(CONFIG_SOC_EXYNOS5420)
# define soc_is_exynos5420() is_samsung_exynos5420()
#else
diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-samsung/include/plat/map-s5p.h
index c186786..804597c 100644
--- a/arch/arm/plat-samsung/include/plat/map-s5p.h
+++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
@@ -23,6 +23,7 @@
#define S5P_VA_SYSRAM S3C_ADDR(0x02400000)
#define S5P_VA_SYSRAM_NS S3C_ADDR(0x02410000)
+
#define S5P_VA_DMC0 S3C_ADDR(0x02440000)
#define S5P_VA_DMC1 S3C_ADDR(0x02480000)
#define S5P_VA_SROMC S3C_ADDR(0x024C0000)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
2014-02-05 5:16 [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC Rahul Sharma
2014-02-05 5:16 ` [PATCH V2 1/3] ARM: EXYNOS: initial board " Rahul Sharma
@ 2014-02-05 5:16 ` Rahul Sharma
2014-02-06 13:21 ` Tomasz Figa
2014-02-05 5:16 ` [PATCH V2 3/3] ARM: dts: add dts files for xyref5260 board Rahul Sharma
2014-02-05 5:31 ` [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC Jingoo Han
3 siblings, 1 reply; 20+ messages in thread
From: Rahul Sharma @ 2014-02-05 5:16 UTC (permalink / raw)
To: linux-samsung-soc; +Cc: kgene.kim, tomasz.figa, joshi, r.sh.open, Rahul Sharma
The patch adds the dts files for exynos5260.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
---
arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572 +++++++++++++++++++++++++++++
arch/arm/boot/dts/exynos5260.dtsi | 317 ++++++++++++++++
2 files changed, 889 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
new file mode 100644
index 0000000..3f2c5c4
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
@@ -0,0 +1,572 @@
+/*
+ * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+ pinctrl@11600000 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb0: gpb0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb1: gpb1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb2: gpb2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb3: gpb3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb4: gpb4 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb5: gpb5 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd2: gpd2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpe0: gpe0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpe1: gpe1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf1: gpf1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpk0: gpk0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpx0: gpx0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpx1: gpx1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpx2: gpx2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpx3: gpx3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ uart0_data: uart0-data {
+ samsung,pins = "gpa0-0", "gpa0-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart0_fctl: uart0-fctl {
+ samsung,pins = "gpa0-2", "gpa0-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_data: uart1-data {
+ samsung,pins = "gpa1-0", "gpa1-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_fctl: uart1-fctl {
+ samsung,pins = "gpa1-2", "gpa1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart2_data: uart2-data {
+ samsung,pins = "gpa1-4", "gpa1-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ spi0_bus: spi0-bus {
+ samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", "gpa2-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ spi1_bus: spi1-bus {
+ samsung,pins = "gpa2-5", "gpa2-6", "gpa2-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ usb3_vbus0_en: usb3-vbus0-en {
+ samsung,pins = "gpa2-4";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2s1_bus: i2s1-bus {
+ samsung,pins = "gpb0-0", "gpb0-1", "gpb0-2", "gpb0-3",
+ "gpb0-4";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ pcm1_bus: pcm1-bus {
+ samsung,pins = "gpb0-0", "gpb0-1", "gpb0-2", "gpb0-3",
+ "gpb0-4";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ spdif1_bus: spdif1-bus {
+ samsung,pins = "gpb0-0", "gpb0-1", "gpb0-2";
+ samsung,pin-function = <4>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ spi2_bus: spi2-bus {
+ samsung,pins = "gpb1-0", "gpb1-1", "gpb1-2", "gpb1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c0_hs_bus: i2c0-hs-bus {
+ samsung,pins = "gpb3-0", "gpb3-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c1_hs_bus: i2c1-hs-bus {
+ samsung,pins = "gpb3-2", "gpb3-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c2_hs_bus: i2c2-hs-bus {
+ samsung,pins = "gpb3-4", "gpb3-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c3_hs_bus: i2c3-hs-bus {
+ samsung,pins = "gpb3-6", "gpb3-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c4_bus: i2c4-bus {
+ samsung,pins = "gpb4-0", "gpb4-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c5_bus: i2c5-bus {
+ samsung,pins = "gpb4-2", "gpb4-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c6_bus: i2c6-bus {
+ samsung,pins = "gpb4-4", "gpb4-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c7_bus: i2c7-bus {
+ samsung,pins = "gpb4-6", "gpb4-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c8_bus: i2c8-bus {
+ samsung,pins = "gpb5-0", "gpb5-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c9_bus: i2c9-bus {
+ samsung,pins = "gpb5-2", "gpb5-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c10_bus: i2c10-bus {
+ samsung,pins = "gpb5-4", "gpb5-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c11_bus: i2c11-bus {
+ samsung,pins = "gpb5-6", "gpb5-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_gpio_a: cam-gpio-a {
+ samsung,pins = "gpe0-0", "gpe0-1", "gpe0-2", "gpe0-3",
+ "gpe0-4", "gpe0-5", "gpe0-6", "gpe0-7",
+ "gpe1-0", "gpe1-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_gpio_b: cam-gpio-b {
+ samsung,pins = "gpf0-0", "gpf0-1", "gpf0-2", "gpf0-3",
+ "gpf1-0", "gpf1-1", "gpf1-2", "gpf1-3";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_i2c1_bus: cam-i2c1-bus {
+ samsung,pins = "gpf0-2", "gpf0-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_i2c0_bus: cam-i2c0-bus {
+ samsung,pins = "gpf0-0", "gpf0-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_spi0_bus: cam-spi0-bus {
+ samsung,pins = "gpf1-0", "gpf1-1", "gpf1-2", "gpf1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_spi1_bus: cam-spi1-bus {
+ samsung,pins = "gpf1-4", "gpf1-5", "gpf1-6", "gpf1-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+ };
+
+ pinctrl@12290000 {
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc2: gpc2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc3: gpc3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc4: gpc4 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ sd0_clk: sd0-clk {
+ samsung,pins = "gpc0-0";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd0_cmd: sd0-cmd {
+ samsung,pins = "gpc0-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd0_bus1: sd0-bus-width1 {
+ samsung,pins = "gpc0-2";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd0_bus4: sd0-bus-width4 {
+ samsung,pins = "gpc0-3", "gpc0-4", "gpc0-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd0_bus8: sd0-bus-width8 {
+ samsung,pins = "gpc3-0", "gpc3-1", "gpc3-2", "gpc3-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd0_rdqs: sd0-rdqs {
+ samsung,pins = "gpc0-6";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd1_clk: sd1-clk {
+ samsung,pins = "gpc1-0";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd1_cmd: sd1-cmd {
+ samsung,pins = "gpc1-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd1_bus1: sd1-bus-width1 {
+ samsung,pins = "gpc1-2";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd1_bus4: sd1-bus-width4 {
+ samsung,pins = "gpc1-3", "gpc1-4", "gpc1-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd1_bus8: sd1-bus-width8 {
+ samsung,pins = "gpc4-0", "gpc4-1", "gpc4-2", "gpc4-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd2_clk: sd2-clk {
+ samsung,pins = "gpc2-0";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd2_cmd: sd2-cmd {
+ samsung,pins = "gpc2-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd2_cd: sd2-cd {
+ samsung,pins = "gpc2-2";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd2_bus1: sd2-bus-width1 {
+ samsung,pins = "gpc2-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd2_bus4: sd2-bus-width4 {
+ samsung,pins = "gpc2-4", "gpc2-5", "gpc2-6";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+ };
+
+ pinctrl@128B0000 {
+ gpz0: gpz0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpz1: gpz1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
new file mode 100644
index 0000000..32a95c7
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -0,0 +1,317 @@
+/*
+ * SAMSUNG EXYNOS5260 SoC device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include "skeleton.dtsi"
+#include "exynos5260-pinctrl.dtsi"
+
+#include <dt-bindings/clk/exynos5260-clk.h>
+
+/ {
+ compatible = "samsung,exynos5260";
+ interrupt-parent = <&gic>;
+
+ aliases {
+ pinctrl0 = &pinctrl_0;
+ pinctrl1 = &pinctrl_1;
+ pinctrl2 = &pinctrl_2;
+ };
+
+ chipid@10000000 {
+ compatible = "samsung,exynos4210-chipid";
+ reg = <0x10000000 0x100>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ cci-control-port = <&cci_control1>;
+ };
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ cci-control-port = <&cci_control1>;
+ };
+ cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x100>;
+ cci-control-port = <&cci_control0>;
+ };
+ cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x101>;
+ cci-control-port = <&cci_control0>;
+ };
+ cpu@102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x102>;
+ cci-control-port = <&cci_control0>;
+ };
+ cpu@103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x103>;
+ cci-control-port = <&cci_control0>;
+ };
+ };
+
+ cmus {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ cmu_top: clock-controller@10010000 {
+ compatible = "exynos5260-cmu-top", "samsung,exynos5260-clock";
+ reg = <0x10010000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_peri: clock-controller@10200000 {
+ compatible = "exynos5260-cmu-peri", "samsung,exynos5260-clock";
+ reg = <0x10200000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_egl: clock-controller@10600000 {
+ compatible = "exynos5260-cmu-egl", "samsung,exynos5260-clock";
+ reg = <0x10600000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_kfc: clock-controller@10700000 {
+ compatible = "exynos5260-cmu-kfc", "samsung,exynos5260-clock";
+ reg = <0x10700000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_g2d: clock-controller@10A00000 {
+ compatible = "exynos5260-cmu-g2d", "samsung,exynos5260-clock";
+ reg = <0x10A00000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_mif: clock-controller@10CE0000 {
+ compatible = "exynos5260-cmu-mif", "samsung,exynos5260-clock";
+ reg = <0x10CE0000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_mfc: clock-controller@11090000 {
+ compatible = "exynos5260-cmu-mfc", "samsung,exynos5260-clock";
+ reg = <0x11090000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_g3d: clock-controller@11830000 {
+ compatible = "exynos5260-cmu-g3d", "samsung,exynos5260-clock";
+ reg = <0x11830000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_fsys: clock-controller@122E0000 {
+ compatible = "exynos5260-cmu-fsys", "samsung,exynos5260-clock";
+ reg = <0x122E0000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_aud: clock-controller@128C0000 {
+ compatible = "exynos5260-cmu-aud", "samsung,exynos5260-clock";
+ reg = <0x128C0000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_isp: clock-controller@133C0000 {
+ compatible = "exynos5260-cmu-isp", "samsung,exynos5260-clock";
+ reg = <0x133C0000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_gscl: clock-controller@13F00000 {
+ compatible = "exynos5260-cmu-gscl", "samsung,exynos5260-clock";
+ reg = <0x13F00000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_disp: clock-controller@14550000 {
+ compatible = "exynos5260-cmu-disp", "samsung,exynos5260-clock";
+ reg = <0x14550000 0x10000>;
+ #clock-cells = <1>;
+ };
+ };
+
+ gic: interrupt-controller@10481000 {
+ compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-controller;
+ reg = <0x10481000 0x1000>,
+ <0x10482000 0x1000>,
+ <0x10484000 0x2000>,
+ <0x10486000 0x2000>;
+ interrupts = <1 9 0xf04>;
+ };
+
+ mct@100B0000 {
+ compatible = "samsung,exynos4210-mct";
+ reg = <0x100B0000 0x1000>;
+ interrupt-controller;
+ #interrups-cells = <1>;
+ interrupt-parent = <&mct_map>;
+ interrupts = <0>, <1>, <2>, <3>,
+ <4>, <5>, <6>, <7>,
+ <8>, <9>, <10>, <11>;
+ clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>;
+ clock-names = "fin_pll", "mct";
+
+ mct_map: mct-map {
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &gic 0 104 0>,
+ <1 &gic 0 105 0>,
+ <2 &gic 0 106 0>,
+ <3 &gic 0 107 0>,
+ <4 &gic 0 122 0>,
+ <5 &gic 0 123 0>,
+ <6 &gic 0 124 0>,
+ <7 &gic 0 125 0>,
+ <8 &gic 0 126 0>,
+ <9 &gic 0 127 0>,
+ <10 &gic 0 128 0>,
+ <11 &gic 0 129 0>;
+ };
+ };
+
+ cci@10F00000 {
+ compatible = "arm,cci-400";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x10F00000 0x1000>;
+ ranges = <0x0 0x10F00000 0x6000>;
+
+ cci_control0: slave-if@4000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x4000 0x1000>;
+ };
+
+ cci_control1: slave-if@5000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x5000 0x1000>;
+ };
+ };
+
+ pinctrl_0: pinctrl@11600000 {
+ compatible = "samsung,exynos5260-pinctrl";
+ reg = <0x11600000 0x1000>;
+ interrupts = <0 79 0>;
+
+ wakeup-interrupt-controller {
+ compatible = "samsung,exynos4210-wakeup-eint";
+ interrupt-parent = <&gic>;
+ interrupts = <0 32 0>;
+ };
+ };
+
+ pinctrl_1: pinctrl@12290000 {
+ compatible = "samsung,exynos5260-pinctrl";
+ reg = <0x12290000 0x1000>;
+ interrupts = <0 157 0>;
+ };
+
+ pinctrl_2: pinctrl@128B0000 {
+ compatible = "samsung,exynos5260-pinctrl";
+ reg = <0x128B0000 0x1000>;
+ interrupts = <0 243 0>;
+ };
+
+ serial@12C00000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12C00000 0x100>;
+ interrupts = <0 146 0>;
+ clocks = <&cmu_peri PERI_CLK_UART0>, <&cmu_peri PERI_SCLK_UART0>;
+ clock-names = "uart", "clk_uart_baud0";
+ status = "disabled";
+ };
+
+ serial@12C10000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12C10000 0x100>;
+ interrupts = <0 147 0>;
+ clocks = <&cmu_peri PERI_CLK_UART1>, <&cmu_peri PERI_SCLK_UART1>;
+ clock-names = "uart", "clk_uart_baud0";
+ status = "disabled";
+ };
+
+ serial@12C20000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12C20000 0x100>;
+ interrupts = <0 148 0>;
+ clocks = <&cmu_peri PERI_CLK_UART2>, <&cmu_peri PERI_SCLK_UART2>;
+ clock-names = "uart", "clk_uart_baud0";
+ status = "disabled";
+ };
+
+ serial@12860000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12860000 0x100>;
+ interrupts = <0 145 0>;
+ clocks = <&cmu_aud AUD_CLK_AUD_UART>, <&cmu_aud AUD_SCLK_AUD_UART>;
+ clock-names = "uart", "clk_uart_baud0";
+ status = "disabled";
+ };
+
+ mmc_0: mmc0@12140000 {
+ compatible = "samsung,exynos5250-dw-mshc";
+ reg = <0x12140000 0x2000>;
+ interrupts = <0 156 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top TOP_SCLK_MMC0>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
+ mmc_1: mmc1@12150000 {
+ compatible = "samsung,exynos5250-dw-mshc";
+ reg = <0x12150000 0x2000>;
+ interrupts = <0 158 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cmu_fsys FSYS_CLK_MMC1>, <&cmu_top TOP_SCLK_MMC1>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
+ mmc_2: mmc2@12160000 {
+ compatible = "samsung,exynos5250-dw-mshc";
+ reg = <0x12160000 0x2000>;
+ interrupts = <0 159 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cmu_fsys FSYS_CLK_MMC2>, <&cmu_top TOP_SCLK_MMC2>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH V2 3/3] ARM: dts: add dts files for xyref5260 board
2014-02-05 5:16 [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC Rahul Sharma
2014-02-05 5:16 ` [PATCH V2 1/3] ARM: EXYNOS: initial board " Rahul Sharma
2014-02-05 5:16 ` [PATCH V2 2/3] ARM: dts: add dts files " Rahul Sharma
@ 2014-02-05 5:16 ` Rahul Sharma
2014-02-05 5:31 ` [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC Jingoo Han
3 siblings, 0 replies; 20+ messages in thread
From: Rahul Sharma @ 2014-02-05 5:16 UTC (permalink / raw)
To: linux-samsung-soc; +Cc: kgene.kim, tomasz.figa, joshi, r.sh.open, Rahul Sharma
The patch adds the dts files for xyref5260 board which
is based on Exynos5260 Evt0 sample.
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts | 105 +++++++++++++++++++++++
2 files changed, 106 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fa70ea2..c513a69 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -64,6 +64,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+ exynos5260-xyref5260-evt0.dtb \
exynos5420-arndale-octa.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
diff --git a/arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts b/arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
new file mode 100644
index 0000000..b4c9c35
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
@@ -0,0 +1,105 @@
+/*
+ * SAMSUNG XYREF5260 EVT0 board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include "exynos5260.dtsi"
+
+/ {
+ model = "SAMSUNG XYREF5260 EVT0 board based on EXYNOS5260";
+ compatible = "samsung,xyref5260", "samsung,exynos5260";
+
+ memory {
+ reg = <0x20000000 0x80000000>;
+ };
+
+ chosen {
+ bootargs = "console=ttySAC2,115200";
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fin_pll: oscillator@0 {
+ compatible = "fixed-clock";
+ reg = <0>;
+ clock-frequency = <24000000>;
+ clock-output-names = "fin_pll";
+ #clock-cells = <0>;
+ };
+ };
+
+ pinctrl@11600000 {
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = "gpx3-7";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
+ };
+ };
+
+ serial@12C00000 {
+ status = "okay";
+ };
+
+ serial@12C10000 {
+ status = "okay";
+ };
+
+ serial@12C20000 {
+ status = "okay";
+ };
+
+ serial@12860000 {
+ status = "okay";
+ };
+
+ mmc0@12140000 {
+ status = "okay";
+ num-slots = <1>;
+ broken-cd;
+ bypass-smu;
+ supports-highspeed;
+ supports-hs200-mode; /* 200 Mhz */
+ fifo-depth = <0x40>;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <0 4>;
+ samsung,dw-mshc-ddr-timing = <0 2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd0_rdqs &sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+ };
+
+ mmc2@12160000 {
+ status = "okay";
+ num-slots = <1>;
+ supports-highspeed;
+ fifo-depth = <0x40>;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <2 3>;
+ samsung,dw-mshc-ddr-timing = <1 2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ disable-wp;
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC
2014-02-05 5:16 [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC Rahul Sharma
` (2 preceding siblings ...)
2014-02-05 5:16 ` [PATCH V2 3/3] ARM: dts: add dts files for xyref5260 board Rahul Sharma
@ 2014-02-05 5:31 ` Jingoo Han
2014-02-05 6:17 ` Rahul Sharma
3 siblings, 1 reply; 20+ messages in thread
From: Jingoo Han @ 2014-02-05 5:31 UTC (permalink / raw)
To: 'Rahul Sharma'
Cc: linux-samsung-soc, 'Kukjin Kim', 'Tomasz Figa',
'Sunil Joshi', 'Rahul Sharma',
'Jingoo Han'
On Wednesday, February 05, 2014 2:16 PM, Rahul Sharma wrote:
>
> This is re-spin of V2 which add arch-side support for exynos5260 SoC.
>
> V2:
> 1) Split up DT patch into SoC and Board patch.
>
> This series is based on Kukjin's for-next branch at
> http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git
>
> Pankaj Dubey (1):
> ARM: EXYNOS: initial board support for exynos5260 SoC
>
> Rahul Sharma (2):
> ARM: dts: add dts files for exynos5260 SoC
> ARM: dts: add dts files for xyref5260 board
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572 +++++++++++++++++++++++
> arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts | 105 +++++
> arch/arm/boot/dts/exynos5260.dtsi | 317 +++++++++++++
> arch/arm/mach-exynos/Kconfig | 9 +
> arch/arm/mach-exynos/common.c | 18 +
> arch/arm/mach-exynos/include/mach/map.h | 1 +
> arch/arm/mach-exynos/mach-exynos5-dt.c | 1 +
> arch/arm/plat-samsung/include/plat/cpu.h | 8 +
> arch/arm/plat-samsung/include/plat/map-s5p.h | 1 +
> 10 files changed, 1033 insertions(+)
> create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
> create mode 100644 arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
> create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
> mode change 100644 => 100755 arch/arm/mach-exynos/include/mach/map.h
> mode change 100644 => 100755 arch/arm/mach-exynos/mach-exynos5-dt.c
> mode change 100644 => 100755 arch/arm/plat-samsung/include/plat/cpu.h
The mode of these three files should NOT be changed to 100755.
Please fix it.
Best regards,
Jingoo Han
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC
2014-02-05 5:31 ` [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC Jingoo Han
@ 2014-02-05 6:17 ` Rahul Sharma
0 siblings, 0 replies; 20+ messages in thread
From: Rahul Sharma @ 2014-02-05 6:17 UTC (permalink / raw)
To: Jingoo Han
Cc: Rahul Sharma, linux-samsung-soc, Kukjin Kim, Tomasz Figa, Sunil Joshi
Oops. Thanks Jingoo Han.
On 5 February 2014 11:01, Jingoo Han <jg1.han@samsung.com> wrote:
> On Wednesday, February 05, 2014 2:16 PM, Rahul Sharma wrote:
>>
>> This is re-spin of V2 which add arch-side support for exynos5260 SoC.
>>
>> V2:
>> 1) Split up DT patch into SoC and Board patch.
>>
>> This series is based on Kukjin's for-next branch at
>> http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git
>>
>> Pankaj Dubey (1):
>> ARM: EXYNOS: initial board support for exynos5260 SoC
>>
>> Rahul Sharma (2):
>> ARM: dts: add dts files for exynos5260 SoC
>> ARM: dts: add dts files for xyref5260 board
>>
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572 +++++++++++++++++++++++
>> arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts | 105 +++++
>> arch/arm/boot/dts/exynos5260.dtsi | 317 +++++++++++++
>> arch/arm/mach-exynos/Kconfig | 9 +
>> arch/arm/mach-exynos/common.c | 18 +
>> arch/arm/mach-exynos/include/mach/map.h | 1 +
>> arch/arm/mach-exynos/mach-exynos5-dt.c | 1 +
>> arch/arm/plat-samsung/include/plat/cpu.h | 8 +
>> arch/arm/plat-samsung/include/plat/map-s5p.h | 1 +
>> 10 files changed, 1033 insertions(+)
>> create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> create mode 100644 arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
>> create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
>> mode change 100644 => 100755 arch/arm/mach-exynos/include/mach/map.h
>> mode change 100644 => 100755 arch/arm/mach-exynos/mach-exynos5-dt.c
>> mode change 100644 => 100755 arch/arm/plat-samsung/include/plat/cpu.h
>
> The mode of these three files should NOT be changed to 100755.
> Please fix it.
>
> Best regards,
> Jingoo Han
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC
2014-02-05 5:16 ` [PATCH V2 1/3] ARM: EXYNOS: initial board " Rahul Sharma
@ 2014-02-05 21:55 ` Olof Johansson
0 siblings, 0 replies; 20+ messages in thread
From: Olof Johansson @ 2014-02-05 21:55 UTC (permalink / raw)
To: Rahul Sharma
Cc: linux-samsung-soc, Kukjin Kim, Tomasz Figa, sunil joshi,
r.sh.open, Pankaj Dubey
Hi,
On Tue, Feb 4, 2014 at 9:16 PM, Rahul Sharma <rahul.sharma@samsung.com> wrote:
> From: Pankaj Dubey <pankaj.dubey@samsung.com>
>
> This patch add basic arch side support for exynos5260 SoC.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
> ---
> arch/arm/mach-exynos/Kconfig | 9 +++++++++
> arch/arm/mach-exynos/common.c | 18 ++++++++++++++++++
> arch/arm/mach-exynos/include/mach/map.h | 1 +
> arch/arm/mach-exynos/mach-exynos5-dt.c | 1 +
> arch/arm/plat-samsung/include/plat/cpu.h | 8 ++++++++
> arch/arm/plat-samsung/include/plat/map-s5p.h | 1 +
> 6 files changed, 38 insertions(+)
> mode change 100644 => 100755 arch/arm/mach-exynos/include/mach/map.h
> mode change 100644 => 100755 arch/arm/mach-exynos/mach-exynos5-dt.c
> mode change 100644 => 100755 arch/arm/plat-samsung/include/plat/cpu.h
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 4c414af..5c96248 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -91,6 +91,15 @@ config SOC_EXYNOS5250
> help
> Enable EXYNOS5250 SoC support
>
> +config SOC_EXYNOS5260
> + bool "SAMSUNG EXYNOS5260"
> + default y
> + depends on ARCH_EXYNOS5
> + select AUTO_ZRELADDR
> + select SAMSUNG_DMADEV
> + help
> + Enable EXYNOS5260 SoC support
There's no point in having one of these for every SoC any more, so
don't add new ones. The amount of code or data added by this is
Kconfig is very small, we can just always include it with any EXYNOS5
build.
> --- a/arch/arm/plat-samsung/include/plat/cpu.h
> +++ b/arch/arm/plat-samsung/include/plat/cpu.h
> @@ -46,6 +46,7 @@ extern unsigned long samsung_cpu_id;
> #define EXYNOS4_CPU_MASK 0xFFFE0000
>
> #define EXYNOS5250_SOC_ID 0x43520000
> +#define EXYNOS5260_SOC_ID 0xE5260000
> #define EXYNOS5420_SOC_ID 0xE5420000
> #define EXYNOS5440_SOC_ID 0xE5440000
> #define EXYNOS5_SOC_MASK 0xFFFFF000
> @@ -68,6 +69,7 @@ IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
> IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
> IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
> IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
> +IS_SAMSUNG_CPU(exynos5260, EXYNOS5260_SOC_ID, EXYNOS5_SOC_MASK)
> IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
> IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
>
> @@ -148,6 +150,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
> # define soc_is_exynos5250() 0
> #endif
>
> +#if defined(CONFIG_SOC_EXYNOS5260)
> +# define soc_is_exynos5260() is_samsung_exynos5260()
> +#else
> +# define soc_is_exynos5260() 0
> +#endif
This will likely conflict with cleanup patches going on right now
which should do away with these header files (or at least move them).
> diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-samsung/include/plat/map-s5p.h
> index c186786..804597c 100644
> --- a/arch/arm/plat-samsung/include/plat/map-s5p.h
> +++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
> @@ -23,6 +23,7 @@
>
> #define S5P_VA_SYSRAM S3C_ADDR(0x02400000)
> #define S5P_VA_SYSRAM_NS S3C_ADDR(0x02410000)
> +
> #define S5P_VA_DMC0 S3C_ADDR(0x02440000)
> #define S5P_VA_DMC1 S3C_ADDR(0x02480000)
> #define S5P_VA_SROMC S3C_ADDR(0x024C0000)
Spurious change.
-Olof
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
2014-02-05 5:16 ` [PATCH V2 2/3] ARM: dts: add dts files " Rahul Sharma
@ 2014-02-06 13:21 ` Tomasz Figa
0 siblings, 0 replies; 20+ messages in thread
From: Tomasz Figa @ 2014-02-06 13:21 UTC (permalink / raw)
To: Rahul Sharma, linux-samsung-soc
Cc: kgene.kim, tomasz.figa, joshi, r.sh.open, devicetree,
linux-arm-kernel, Rob Herring, Mark Rutland, Grant Likely,
Ian Campbell, Pawel Moll, Kumar Gala
Hi Rahul, Pankaj, Arun,
[adding linux-arm-kernel, devicetree MLs and DT people on Cc]
I think it's good time to stop accepting DTS files like this and force
new ones to use the proper structure with soc node, labels for every
node and node references.
In case of previous Exynos 5 SoCs I hadn't complained, because they
shared a lot of data with already existing exynos5.dtsi, but since
Exynos5260 is completely different, I'd say it should be converted to
the new layout.
As an example you can look at arch/arm/boot/dts/s3c64xx.dtsi and files
that include it or, for more complete structures, DTS of other
platforms, such as imx6*.
Btw. Please remember that linux-samsung-soc mailing list is just a
convenient utility for reviewers of Samsung-specific patches to have all
of them in one place. Sending patches to it alone is not enough - a
general kernel ML list needs to be CCed as well, in this case
linux-arm-kernel.
Also, please see my comments inline, for review comments unrelated to
the issue described above.
On 05.02.2014 06:16, Rahul Sharma wrote:
> The patch adds the dts files for exynos5260.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
> Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
> ---
> arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572 +++++++++++++++++++++++++++++
> arch/arm/boot/dts/exynos5260.dtsi | 317 ++++++++++++++++
> 2 files changed, 889 insertions(+)
> create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
> create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
>
> diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
> new file mode 100644
> index 0000000..3f2c5c4
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
> @@ -0,0 +1,572 @@
> +/*
> + * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
> + *
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as device
> + * tree nodes are listed in this file.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +/ {
> + pinctrl@11600000 {
[snip]
> + spi0_bus: spi0-bus {
> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", "gpa2-3";
What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
> + samsung,pin-function = <2>;
> + samsung,pin-pud = <3>;
> + samsung,pin-drv = <0>;
> + };
[snip]
> diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
> new file mode 100644
> index 0000000..32a95c7
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5260.dtsi
> @@ -0,0 +1,317 @@
> +/*
> + * SAMSUNG EXYNOS5260 SoC device tree source
> + *
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include "skeleton.dtsi"
> +#include "exynos5260-pinctrl.dtsi"
> +
> +#include <dt-bindings/clk/exynos5260-clk.h>
> +
> +/ {
> + compatible = "samsung,exynos5260";
> + interrupt-parent = <&gic>;
> +
> + aliases {
> + pinctrl0 = &pinctrl_0;
> + pinctrl1 = &pinctrl_1;
> + pinctrl2 = &pinctrl_2;
> + };
> +
> + chipid@10000000 {
> + compatible = "samsung,exynos4210-chipid";
> + reg = <0x10000000 0x100>;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0>;
nit: Please make this consistent with CPUs 10x below, by using hex here
as well.
> + cci-control-port = <&cci_control1>;
> + };
nit: Please keep 1 blank line of spacing between nodes.
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <1>;
> + cci-control-port = <&cci_control1>;
> + };
> + cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x100>;
> + cci-control-port = <&cci_control0>;
> + };
> + cpu@101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x101>;
> + cci-control-port = <&cci_control0>;
> + };
> + cpu@102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x102>;
> + cci-control-port = <&cci_control0>;
> + };
> + cpu@103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x103>;
> + cci-control-port = <&cci_control0>;
> + };
> + };
> +
> + cmus {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
I don't think there is a need to group these nodes under a parent node
that doesn't give any additional information, especially when the CMUs
are scattered trough the whole address space, while we'd like to keep
the nodes ordered by their addresses, as most platforms do.
> + cmu_top: clock-controller@10010000 {
> + compatible = "exynos5260-cmu-top", "samsung,exynos5260-clock";
I don't think that having the "samsung,exynos5260-clock" compatible
string for every CMU is appropriate here, because there is no way to
automatically recognize which CMU it is. Since every CMU instance is
different, they need to have different compatible strings.
> + reg = <0x10010000 0x10000>;
> + #clock-cells = <1>;
> + };
[snip]
> + mct@100B0000 {
> + compatible = "samsung,exynos4210-mct";
> + reg = <0x100B0000 0x1000>;
> + interrupt-controller;
> + #interrups-cells = <1>;
MCT is not an interrupt controller, so the 2 properties above are incorrect.
> + interrupt-parent = <&mct_map>;
> + interrupts = <0>, <1>, <2>, <3>,
> + <4>, <5>, <6>, <7>,
> + <8>, <9>, <10>, <11>;
> + clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>;
> + clock-names = "fin_pll", "mct";
> +
> + mct_map: mct-map {
> + #interrupt-cells = <1>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + interrupt-map = <0 &gic 0 104 0>,
> + <1 &gic 0 105 0>,
> + <2 &gic 0 106 0>,
> + <3 &gic 0 107 0>,
> + <4 &gic 0 122 0>,
> + <5 &gic 0 123 0>,
> + <6 &gic 0 124 0>,
> + <7 &gic 0 125 0>,
> + <8 &gic 0 126 0>,
> + <9 &gic 0 127 0>,
> + <10 &gic 0 128 0>,
> + <11 &gic 0 129 0>;
> + };
There is no need for interrupt-map here, because all the interrupts are
from GIC.
> + };
[snip]
> + mmc_0: mmc0@12140000 {
> + compatible = "samsung,exynos5250-dw-mshc";
> + reg = <0x12140000 0x2000>;
> + interrupts = <0 156 0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top TOP_SCLK_MMC0>;
> + clock-names = "biu", "ciu";
> + fifo-depth = <0x40>;
nit: It might be more readable to use decimal 64 here.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
@ 2014-02-06 13:21 ` Tomasz Figa
0 siblings, 0 replies; 20+ messages in thread
From: Tomasz Figa @ 2014-02-06 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rahul, Pankaj, Arun,
[adding linux-arm-kernel, devicetree MLs and DT people on Cc]
I think it's good time to stop accepting DTS files like this and force
new ones to use the proper structure with soc node, labels for every
node and node references.
In case of previous Exynos 5 SoCs I hadn't complained, because they
shared a lot of data with already existing exynos5.dtsi, but since
Exynos5260 is completely different, I'd say it should be converted to
the new layout.
As an example you can look at arch/arm/boot/dts/s3c64xx.dtsi and files
that include it or, for more complete structures, DTS of other
platforms, such as imx6*.
Btw. Please remember that linux-samsung-soc mailing list is just a
convenient utility for reviewers of Samsung-specific patches to have all
of them in one place. Sending patches to it alone is not enough - a
general kernel ML list needs to be CCed as well, in this case
linux-arm-kernel.
Also, please see my comments inline, for review comments unrelated to
the issue described above.
On 05.02.2014 06:16, Rahul Sharma wrote:
> The patch adds the dts files for exynos5260.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
> Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
> ---
> arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572 +++++++++++++++++++++++++++++
> arch/arm/boot/dts/exynos5260.dtsi | 317 ++++++++++++++++
> 2 files changed, 889 insertions(+)
> create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
> create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
>
> diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
> new file mode 100644
> index 0000000..3f2c5c4
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
> @@ -0,0 +1,572 @@
> +/*
> + * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
> + *
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as device
> + * tree nodes are listed in this file.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +/ {
> + pinctrl at 11600000 {
[snip]
> + spi0_bus: spi0-bus {
> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", "gpa2-3";
What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
> + samsung,pin-function = <2>;
> + samsung,pin-pud = <3>;
> + samsung,pin-drv = <0>;
> + };
[snip]
> diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
> new file mode 100644
> index 0000000..32a95c7
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5260.dtsi
> @@ -0,0 +1,317 @@
> +/*
> + * SAMSUNG EXYNOS5260 SoC device tree source
> + *
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include "skeleton.dtsi"
> +#include "exynos5260-pinctrl.dtsi"
> +
> +#include <dt-bindings/clk/exynos5260-clk.h>
> +
> +/ {
> + compatible = "samsung,exynos5260";
> + interrupt-parent = <&gic>;
> +
> + aliases {
> + pinctrl0 = &pinctrl_0;
> + pinctrl1 = &pinctrl_1;
> + pinctrl2 = &pinctrl_2;
> + };
> +
> + chipid at 10000000 {
> + compatible = "samsung,exynos4210-chipid";
> + reg = <0x10000000 0x100>;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0>;
nit: Please make this consistent with CPUs 10x below, by using hex here
as well.
> + cci-control-port = <&cci_control1>;
> + };
nit: Please keep 1 blank line of spacing between nodes.
> + cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <1>;
> + cci-control-port = <&cci_control1>;
> + };
> + cpu at 100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x100>;
> + cci-control-port = <&cci_control0>;
> + };
> + cpu at 101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x101>;
> + cci-control-port = <&cci_control0>;
> + };
> + cpu at 102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x102>;
> + cci-control-port = <&cci_control0>;
> + };
> + cpu at 103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x103>;
> + cci-control-port = <&cci_control0>;
> + };
> + };
> +
> + cmus {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
I don't think there is a need to group these nodes under a parent node
that doesn't give any additional information, especially when the CMUs
are scattered trough the whole address space, while we'd like to keep
the nodes ordered by their addresses, as most platforms do.
> + cmu_top: clock-controller at 10010000 {
> + compatible = "exynos5260-cmu-top", "samsung,exynos5260-clock";
I don't think that having the "samsung,exynos5260-clock" compatible
string for every CMU is appropriate here, because there is no way to
automatically recognize which CMU it is. Since every CMU instance is
different, they need to have different compatible strings.
> + reg = <0x10010000 0x10000>;
> + #clock-cells = <1>;
> + };
[snip]
> + mct at 100B0000 {
> + compatible = "samsung,exynos4210-mct";
> + reg = <0x100B0000 0x1000>;
> + interrupt-controller;
> + #interrups-cells = <1>;
MCT is not an interrupt controller, so the 2 properties above are incorrect.
> + interrupt-parent = <&mct_map>;
> + interrupts = <0>, <1>, <2>, <3>,
> + <4>, <5>, <6>, <7>,
> + <8>, <9>, <10>, <11>;
> + clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>;
> + clock-names = "fin_pll", "mct";
> +
> + mct_map: mct-map {
> + #interrupt-cells = <1>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + interrupt-map = <0 &gic 0 104 0>,
> + <1 &gic 0 105 0>,
> + <2 &gic 0 106 0>,
> + <3 &gic 0 107 0>,
> + <4 &gic 0 122 0>,
> + <5 &gic 0 123 0>,
> + <6 &gic 0 124 0>,
> + <7 &gic 0 125 0>,
> + <8 &gic 0 126 0>,
> + <9 &gic 0 127 0>,
> + <10 &gic 0 128 0>,
> + <11 &gic 0 129 0>;
> + };
There is no need for interrupt-map here, because all the interrupts are
from GIC.
> + };
[snip]
> + mmc_0: mmc0 at 12140000 {
> + compatible = "samsung,exynos5250-dw-mshc";
> + reg = <0x12140000 0x2000>;
> + interrupts = <0 156 0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top TOP_SCLK_MMC0>;
> + clock-names = "biu", "ciu";
> + fifo-depth = <0x40>;
nit: It might be more readable to use decimal 64 here.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
2014-02-06 13:21 ` Tomasz Figa
@ 2014-02-11 5:22 ` Rahul Sharma
-1 siblings, 0 replies; 20+ messages in thread
From: Rahul Sharma @ 2014-02-11 5:22 UTC (permalink / raw)
To: Tomasz Figa
Cc: Rahul Sharma, linux-samsung-soc, Kukjin Kim, Tomasz Figa,
sunil joshi, devicetree, linux-arm-kernel, Rob Herring,
Mark Rutland, Grant Likely, Ian Campbell, Pawel Moll, Kumar Gala
Hi Tomasz,
On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
> Hi Rahul, Pankaj, Arun,
>
> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>
> I think it's good time to stop accepting DTS files like this and force new
> ones to use the proper structure with soc node, labels for every node and
> node references.
I am unable to find information on SoC node and grouping inside SoC node. Please
share some pointers.
>
> In case of previous Exynos 5 SoCs I hadn't complained, because they shared a
> lot of data with already existing exynos5.dtsi, but since Exynos5260 is
> completely different, I'd say it should be converted to the new layout.
>
> As an example you can look at arch/arm/boot/dts/s3c64xx.dtsi and files that
> include it or, for more complete structures, DTS of other platforms, such as
> imx6*.
>
> Btw. Please remember that linux-samsung-soc mailing list is just a
> convenient utility for reviewers of Samsung-specific patches to have all of
> them in one place. Sending patches to it alone is not enough - a general
> kernel ML list needs to be CCed as well, in this case linux-arm-kernel.
>
I will take care of this.
> Also, please see my comments inline, for review comments unrelated to the
> issue described above.
>
>
> On 05.02.2014 06:16, Rahul Sharma wrote:
>>
>> The patch adds the dts files for exynos5260.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
>> Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
>> ---
>> arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572
>> +++++++++++++++++++++++++++++
>> arch/arm/boot/dts/exynos5260.dtsi | 317 ++++++++++++++++
>> 2 files changed, 889 insertions(+)
>> create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
>>
>> diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> new file mode 100644
>> index 0000000..3f2c5c4
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> @@ -0,0 +1,572 @@
>> +/*
>> + * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
>> + *
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as
>> device
>> + * tree nodes are listed in this file.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +/ {
>> + pinctrl@11600000 {
>
>
> [snip]
>
>
>> + spi0_bus: spi0-bus {
>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>> "gpa2-3";
>
>
> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>
I should align SPI1 with SPI0.
>
>> + samsung,pin-function = <2>;
>> + samsung,pin-pud = <3>;
>> + samsung,pin-drv = <0>;
>> + };
>
>
> [snip]
>
>
>> diff --git a/arch/arm/boot/dts/exynos5260.dtsi
>> b/arch/arm/boot/dts/exynos5260.dtsi
>> new file mode 100644
>> index 0000000..32a95c7
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5260.dtsi
>> @@ -0,0 +1,317 @@
>> +/*
>> + * SAMSUNG EXYNOS5260 SoC device tree source
>> + *
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +#include "skeleton.dtsi"
>> +#include "exynos5260-pinctrl.dtsi"
>> +
>> +#include <dt-bindings/clk/exynos5260-clk.h>
>> +
>> +/ {
>> + compatible = "samsung,exynos5260";
>> + interrupt-parent = <&gic>;
>> +
>> + aliases {
>> + pinctrl0 = &pinctrl_0;
>> + pinctrl1 = &pinctrl_1;
>> + pinctrl2 = &pinctrl_2;
>> + };
>> +
>> + chipid@10000000 {
>> + compatible = "samsung,exynos4210-chipid";
>> + reg = <0x10000000 0x100>;
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a15";
>> + reg = <0>;
>
>
> nit: Please make this consistent with CPUs 10x below, by using hex here as
> well.
>
Done.
>
>> + cci-control-port = <&cci_control1>;
>> + };
>
>
> nit: Please keep 1 blank line of spacing between nodes.
>
ok.
>
>> + cpu@1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a15";
>> + reg = <1>;
>> + cci-control-port = <&cci_control1>;
>> + };
>> + cpu@100 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x100>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu@101 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x101>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu@102 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x102>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu@103 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x103>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + };
>> +
>> + cmus {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>
>
> I don't think there is a need to group these nodes under a parent node that
> doesn't give any additional information, especially when the CMUs are
> scattered trough the whole address space, while we'd like to keep the nodes
> ordered by their addresses, as most platforms do.
>
This is exactly the same case as "cpus". I mean, "cpus" also doesn't provide
any common information about child cpu nodes. This looks to me as a logical
grouping and I have implemented same thing for cmu nodes.
I am ok with removing this grouping Just want to understand the rational behind
grouping cpus which seems similar to cmus.
Similarly "soc" is just a logical entity used to group SoC elements which looks
optional to me. What are we achieving with this? Please help me in understanding
this better.
>
>> + cmu_top: clock-controller@10010000 {
>> + compatible = "exynos5260-cmu-top",
>> "samsung,exynos5260-clock";
>
>
> I don't think that having the "samsung,exynos5260-clock" compatible string
> for every CMU is appropriate here, because there is no way to automatically
> recognize which CMU it is. Since every CMU instance is different, they need
> to have different compatible strings.
>
Changed.
>
>> + reg = <0x10010000 0x10000>;
>> + #clock-cells = <1>;
>> + };
>
>
> [snip]
>
>
>> + mct@100B0000 {
>> + compatible = "samsung,exynos4210-mct";
>> + reg = <0x100B0000 0x1000>;
>> + interrupt-controller;
>> + #interrups-cells = <1>;
>
>
> MCT is not an interrupt controller, so the 2 properties above are incorrect.
>
Agree. I will change this.
>
>> + interrupt-parent = <&mct_map>;
>> + interrupts = <0>, <1>, <2>, <3>,
>> + <4>, <5>, <6>, <7>,
>> + <8>, <9>, <10>, <11>;
>> + clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>;
>> + clock-names = "fin_pll", "mct";
>> +
>> + mct_map: mct-map {
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = <0 &gic 0 104 0>,
>> + <1 &gic 0 105 0>,
>> + <2 &gic 0 106 0>,
>> + <3 &gic 0 107 0>,
>> + <4 &gic 0 122 0>,
>> + <5 &gic 0 123 0>,
>> + <6 &gic 0 124 0>,
>> + <7 &gic 0 125 0>,
>> + <8 &gic 0 126 0>,
>> + <9 &gic 0 127 0>,
>> + <10 &gic 0 128 0>,
>> + <11 &gic 0 129 0>;
>> + };
>
>
> There is no need for interrupt-map here, because all the interrupts are from
> GIC.
>
Done.
Regards,
Rahul Sharma.
>> + };
>
>
> [snip]
>
>
>> + mmc_0: mmc0@12140000 {
>> + compatible = "samsung,exynos5250-dw-mshc";
>> + reg = <0x12140000 0x2000>;
>> + interrupts = <0 156 0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top
>> TOP_SCLK_MMC0>;
>> + clock-names = "biu", "ciu";
>> + fifo-depth = <0x40>;
>
>
> nit: It might be more readable to use decimal 64 here.
>
> Best regards,
> Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
@ 2014-02-11 5:22 ` Rahul Sharma
0 siblings, 0 replies; 20+ messages in thread
From: Rahul Sharma @ 2014-02-11 5:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomasz,
On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
> Hi Rahul, Pankaj, Arun,
>
> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>
> I think it's good time to stop accepting DTS files like this and force new
> ones to use the proper structure with soc node, labels for every node and
> node references.
I am unable to find information on SoC node and grouping inside SoC node. Please
share some pointers.
>
> In case of previous Exynos 5 SoCs I hadn't complained, because they shared a
> lot of data with already existing exynos5.dtsi, but since Exynos5260 is
> completely different, I'd say it should be converted to the new layout.
>
> As an example you can look at arch/arm/boot/dts/s3c64xx.dtsi and files that
> include it or, for more complete structures, DTS of other platforms, such as
> imx6*.
>
> Btw. Please remember that linux-samsung-soc mailing list is just a
> convenient utility for reviewers of Samsung-specific patches to have all of
> them in one place. Sending patches to it alone is not enough - a general
> kernel ML list needs to be CCed as well, in this case linux-arm-kernel.
>
I will take care of this.
> Also, please see my comments inline, for review comments unrelated to the
> issue described above.
>
>
> On 05.02.2014 06:16, Rahul Sharma wrote:
>>
>> The patch adds the dts files for exynos5260.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
>> Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
>> ---
>> arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572
>> +++++++++++++++++++++++++++++
>> arch/arm/boot/dts/exynos5260.dtsi | 317 ++++++++++++++++
>> 2 files changed, 889 insertions(+)
>> create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
>>
>> diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> new file mode 100644
>> index 0000000..3f2c5c4
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> @@ -0,0 +1,572 @@
>> +/*
>> + * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
>> + *
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as
>> device
>> + * tree nodes are listed in this file.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +/ {
>> + pinctrl at 11600000 {
>
>
> [snip]
>
>
>> + spi0_bus: spi0-bus {
>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>> "gpa2-3";
>
>
> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>
I should align SPI1 with SPI0.
>
>> + samsung,pin-function = <2>;
>> + samsung,pin-pud = <3>;
>> + samsung,pin-drv = <0>;
>> + };
>
>
> [snip]
>
>
>> diff --git a/arch/arm/boot/dts/exynos5260.dtsi
>> b/arch/arm/boot/dts/exynos5260.dtsi
>> new file mode 100644
>> index 0000000..32a95c7
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5260.dtsi
>> @@ -0,0 +1,317 @@
>> +/*
>> + * SAMSUNG EXYNOS5260 SoC device tree source
>> + *
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +#include "skeleton.dtsi"
>> +#include "exynos5260-pinctrl.dtsi"
>> +
>> +#include <dt-bindings/clk/exynos5260-clk.h>
>> +
>> +/ {
>> + compatible = "samsung,exynos5260";
>> + interrupt-parent = <&gic>;
>> +
>> + aliases {
>> + pinctrl0 = &pinctrl_0;
>> + pinctrl1 = &pinctrl_1;
>> + pinctrl2 = &pinctrl_2;
>> + };
>> +
>> + chipid at 10000000 {
>> + compatible = "samsung,exynos4210-chipid";
>> + reg = <0x10000000 0x100>;
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu at 0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a15";
>> + reg = <0>;
>
>
> nit: Please make this consistent with CPUs 10x below, by using hex here as
> well.
>
Done.
>
>> + cci-control-port = <&cci_control1>;
>> + };
>
>
> nit: Please keep 1 blank line of spacing between nodes.
>
ok.
>
>> + cpu at 1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a15";
>> + reg = <1>;
>> + cci-control-port = <&cci_control1>;
>> + };
>> + cpu at 100 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x100>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu at 101 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x101>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu at 102 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x102>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu at 103 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x103>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + };
>> +
>> + cmus {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>
>
> I don't think there is a need to group these nodes under a parent node that
> doesn't give any additional information, especially when the CMUs are
> scattered trough the whole address space, while we'd like to keep the nodes
> ordered by their addresses, as most platforms do.
>
This is exactly the same case as "cpus". I mean, "cpus" also doesn't provide
any common information about child cpu nodes. This looks to me as a logical
grouping and I have implemented same thing for cmu nodes.
I am ok with removing this grouping Just want to understand the rational behind
grouping cpus which seems similar to cmus.
Similarly "soc" is just a logical entity used to group SoC elements which looks
optional to me. What are we achieving with this? Please help me in understanding
this better.
>
>> + cmu_top: clock-controller at 10010000 {
>> + compatible = "exynos5260-cmu-top",
>> "samsung,exynos5260-clock";
>
>
> I don't think that having the "samsung,exynos5260-clock" compatible string
> for every CMU is appropriate here, because there is no way to automatically
> recognize which CMU it is. Since every CMU instance is different, they need
> to have different compatible strings.
>
Changed.
>
>> + reg = <0x10010000 0x10000>;
>> + #clock-cells = <1>;
>> + };
>
>
> [snip]
>
>
>> + mct at 100B0000 {
>> + compatible = "samsung,exynos4210-mct";
>> + reg = <0x100B0000 0x1000>;
>> + interrupt-controller;
>> + #interrups-cells = <1>;
>
>
> MCT is not an interrupt controller, so the 2 properties above are incorrect.
>
Agree. I will change this.
>
>> + interrupt-parent = <&mct_map>;
>> + interrupts = <0>, <1>, <2>, <3>,
>> + <4>, <5>, <6>, <7>,
>> + <8>, <9>, <10>, <11>;
>> + clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>;
>> + clock-names = "fin_pll", "mct";
>> +
>> + mct_map: mct-map {
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = <0 &gic 0 104 0>,
>> + <1 &gic 0 105 0>,
>> + <2 &gic 0 106 0>,
>> + <3 &gic 0 107 0>,
>> + <4 &gic 0 122 0>,
>> + <5 &gic 0 123 0>,
>> + <6 &gic 0 124 0>,
>> + <7 &gic 0 125 0>,
>> + <8 &gic 0 126 0>,
>> + <9 &gic 0 127 0>,
>> + <10 &gic 0 128 0>,
>> + <11 &gic 0 129 0>;
>> + };
>
>
> There is no need for interrupt-map here, because all the interrupts are from
> GIC.
>
Done.
Regards,
Rahul Sharma.
>> + };
>
>
> [snip]
>
>
>> + mmc_0: mmc0 at 12140000 {
>> + compatible = "samsung,exynos5250-dw-mshc";
>> + reg = <0x12140000 0x2000>;
>> + interrupts = <0 156 0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top
>> TOP_SCLK_MMC0>;
>> + clock-names = "biu", "ciu";
>> + fifo-depth = <0x40>;
>
>
> nit: It might be more readable to use decimal 64 here.
>
> Best regards,
> Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
2014-02-11 5:22 ` Rahul Sharma
@ 2014-02-11 10:04 ` Tomasz Figa
-1 siblings, 0 replies; 20+ messages in thread
From: Tomasz Figa @ 2014-02-11 10:04 UTC (permalink / raw)
To: Rahul Sharma, Tomasz Figa
Cc: Rahul Sharma, linux-samsung-soc, Kukjin Kim, sunil joshi,
devicetree, linux-arm-kernel, Rob Herring, Mark Rutland,
Grant Likely, Ian Campbell, Pawel Moll, Kumar Gala
Hi Rahul,
On 11.02.2014 06:22, Rahul Sharma wrote:
> Hi Tomasz,
>
> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
>> Hi Rahul, Pankaj, Arun,
>>
>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>>
>> I think it's good time to stop accepting DTS files like this and force new
>> ones to use the proper structure with soc node, labels for every node and
>> node references.
>
> I am unable to find information on SoC node and grouping inside SoC node. Please
> share some pointers.
Well, there is not much information needed about this. Basically all the
devices built into the SoC should be listed under respective bus nodes
or a single soc node, instead of root level. Such node should be a
"simple-bus" and just group the components together to separate
board-specific devices (which are still at root level) from SoC devices.
Even though it might seem useless, it improves DT readability a bit and
still most of the platforms use this approach, so for consistency,
Exynos should use too.
Just for reference, back in April 2013, in his review of S3C64xx DT
series [1], Rob Herring requested that we don't submit any new device
trees using flat approach and start using bus hierarchy.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
>>
>>> + spi0_bus: spi0-bus {
>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>>> "gpa2-3";
>>
>>
>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>>
>
> I should align SPI1 with SPI0.
>
Are you sure that SPI0 is the correct one? SPI usually uses four pins -
SDI, SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO,
due to the fact that the controller can only support one dedicated chip
select and with direct GPIO control you can have more.
What is the fourth pin here?
>>
>>> + cpu@1 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a15";
>>> + reg = <1>;
>>> + cci-control-port = <&cci_control1>;
>>> + };
>>> + cpu@100 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a7";
>>> + reg = <0x100>;
>>> + cci-control-port = <&cci_control0>;
>>> + };
>>> + cpu@101 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a7";
>>> + reg = <0x101>;
>>> + cci-control-port = <&cci_control0>;
>>> + };
>>> + cpu@102 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a7";
>>> + reg = <0x102>;
>>> + cci-control-port = <&cci_control0>;
>>> + };
>>> + cpu@103 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a7";
>>> + reg = <0x103>;
>>> + cci-control-port = <&cci_control0>;
>>> + };
>>> + };
>>> +
>>> + cmus {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> +
>>
>>
>> I don't think there is a need to group these nodes under a parent node that
>> doesn't give any additional information, especially when the CMUs are
>> scattered trough the whole address space, while we'd like to keep the nodes
>> ordered by their addresses, as most platforms do.
>>
>
> This is exactly the same case as "cpus". I mean, "cpus" also doesn't provide
> any common information about child cpu nodes. This looks to me as a logical
> grouping and I have implemented same thing for cmu nodes.
> I am ok with removing this grouping Just want to understand the rational behind
> grouping cpus which seems similar to cmus.
The "cpus" node is a defined standard node that should be present at
root of device tree and include subnodes for all CPUs. This is a
standard binding defined for low level code to be able to simply find
nodes of all CPUs in the system - so they can expect that at /cpus node
all the subnodes are subsequent CPUs.
> Similarly "soc" is just a logical entity used to group SoC elements which looks
> optional to me. What are we achieving with this? Please help me in understanding
> this better.
Also "soc" has a slightly wider meaning. It is a node grouping all nodes
from a single address space - the node specifies #address-cells and
#size-cells of this address space and all the devices under this
"simple-bus" can be accessed using addresses in this format. In
addition, it separates board-level devices from generic SoC devices.
Now, in case of "cmus", the only purpose is to group all CMU nodes
together and, while this improves readability a bit, it doesn't make the
DT better express the hardware topology, because the CMUs in the
hardware are in fact scattered through the whole address space, not
under a contiguous block of it, as the grouping would suggest.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
@ 2014-02-11 10:04 ` Tomasz Figa
0 siblings, 0 replies; 20+ messages in thread
From: Tomasz Figa @ 2014-02-11 10:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rahul,
On 11.02.2014 06:22, Rahul Sharma wrote:
> Hi Tomasz,
>
> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
>> Hi Rahul, Pankaj, Arun,
>>
>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>>
>> I think it's good time to stop accepting DTS files like this and force new
>> ones to use the proper structure with soc node, labels for every node and
>> node references.
>
> I am unable to find information on SoC node and grouping inside SoC node. Please
> share some pointers.
Well, there is not much information needed about this. Basically all the
devices built into the SoC should be listed under respective bus nodes
or a single soc node, instead of root level. Such node should be a
"simple-bus" and just group the components together to separate
board-specific devices (which are still at root level) from SoC devices.
Even though it might seem useless, it improves DT readability a bit and
still most of the platforms use this approach, so for consistency,
Exynos should use too.
Just for reference, back in April 2013, in his review of S3C64xx DT
series [1], Rob Herring requested that we don't submit any new device
trees using flat approach and start using bus hierarchy.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
>>
>>> + spi0_bus: spi0-bus {
>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>>> "gpa2-3";
>>
>>
>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>>
>
> I should align SPI1 with SPI0.
>
Are you sure that SPI0 is the correct one? SPI usually uses four pins -
SDI, SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO,
due to the fact that the controller can only support one dedicated chip
select and with direct GPIO control you can have more.
What is the fourth pin here?
>>
>>> + cpu at 1 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a15";
>>> + reg = <1>;
>>> + cci-control-port = <&cci_control1>;
>>> + };
>>> + cpu at 100 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a7";
>>> + reg = <0x100>;
>>> + cci-control-port = <&cci_control0>;
>>> + };
>>> + cpu at 101 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a7";
>>> + reg = <0x101>;
>>> + cci-control-port = <&cci_control0>;
>>> + };
>>> + cpu at 102 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a7";
>>> + reg = <0x102>;
>>> + cci-control-port = <&cci_control0>;
>>> + };
>>> + cpu at 103 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a7";
>>> + reg = <0x103>;
>>> + cci-control-port = <&cci_control0>;
>>> + };
>>> + };
>>> +
>>> + cmus {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> +
>>
>>
>> I don't think there is a need to group these nodes under a parent node that
>> doesn't give any additional information, especially when the CMUs are
>> scattered trough the whole address space, while we'd like to keep the nodes
>> ordered by their addresses, as most platforms do.
>>
>
> This is exactly the same case as "cpus". I mean, "cpus" also doesn't provide
> any common information about child cpu nodes. This looks to me as a logical
> grouping and I have implemented same thing for cmu nodes.
> I am ok with removing this grouping Just want to understand the rational behind
> grouping cpus which seems similar to cmus.
The "cpus" node is a defined standard node that should be present at
root of device tree and include subnodes for all CPUs. This is a
standard binding defined for low level code to be able to simply find
nodes of all CPUs in the system - so they can expect that at /cpus node
all the subnodes are subsequent CPUs.
> Similarly "soc" is just a logical entity used to group SoC elements which looks
> optional to me. What are we achieving with this? Please help me in understanding
> this better.
Also "soc" has a slightly wider meaning. It is a node grouping all nodes
from a single address space - the node specifies #address-cells and
#size-cells of this address space and all the devices under this
"simple-bus" can be accessed using addresses in this format. In
addition, it separates board-level devices from generic SoC devices.
Now, in case of "cmus", the only purpose is to group all CMU nodes
together and, while this improves readability a bit, it doesn't make the
DT better express the hardware topology, because the CMUs in the
hardware are in fact scattered through the whole address space, not
under a contiguous block of it, as the grouping would suggest.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
2014-02-11 10:04 ` Tomasz Figa
@ 2014-02-14 3:24 ` Rahul Sharma
-1 siblings, 0 replies; 20+ messages in thread
From: Rahul Sharma @ 2014-02-14 3:24 UTC (permalink / raw)
To: Tomasz Figa
Cc: Tomasz Figa, Rahul Sharma, linux-samsung-soc, Kukjin Kim,
sunil joshi, devicetree, linux-arm-kernel, Rob Herring,
Mark Rutland, Grant Likely, Ian Campbell, Pawel Moll, Kumar Gala
Thanks Tomasz,
I will add these changes to v3.
Regards,
Rahul Sharma.
On 11 February 2014 15:34, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Hi Rahul,
>
>
> On 11.02.2014 06:22, Rahul Sharma wrote:
>>
>> Hi Tomasz,
>>
>> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
>>>
>>> Hi Rahul, Pankaj, Arun,
>>>
>>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>>>
>>> I think it's good time to stop accepting DTS files like this and force
>>> new
>>> ones to use the proper structure with soc node, labels for every node and
>>> node references.
>>
>>
>> I am unable to find information on SoC node and grouping inside SoC node.
>> Please
>> share some pointers.
>
>
> Well, there is not much information needed about this. Basically all the
> devices built into the SoC should be listed under respective bus nodes or a
> single soc node, instead of root level. Such node should be a "simple-bus"
> and just group the components together to separate board-specific devices
> (which are still at root level) from SoC devices.
>
> Even though it might seem useless, it improves DT readability a bit and
> still most of the platforms use this approach, so for consistency, Exynos
> should use too.
>
> Just for reference, back in April 2013, in his review of S3C64xx DT series
> [1], Rob Herring requested that we don't submit any new device trees using
> flat approach and start using bus hierarchy.
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
>
>
>>>
>>>> + spi0_bus: spi0-bus {
>>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>>>> "gpa2-3";
>>>
>>>
>>>
>>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>>>
>>
>> I should align SPI1 with SPI0.
>>
>
> Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI,
> SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to
> the fact that the controller can only support one dedicated chip select and
> with direct GPIO control you can have more.
>
> What is the fourth pin here?
>
>
>>>
>>>> + cpu@1 {
>>>> + device_type = "cpu";
>>>> + compatible = "arm,cortex-a15";
>>>> + reg = <1>;
>>>> + cci-control-port = <&cci_control1>;
>>>> + };
>>>> + cpu@100 {
>>>> + device_type = "cpu";
>>>> + compatible = "arm,cortex-a7";
>>>> + reg = <0x100>;
>>>> + cci-control-port = <&cci_control0>;
>>>> + };
>>>> + cpu@101 {
>>>> + device_type = "cpu";
>>>> + compatible = "arm,cortex-a7";
>>>> + reg = <0x101>;
>>>> + cci-control-port = <&cci_control0>;
>>>> + };
>>>> + cpu@102 {
>>>> + device_type = "cpu";
>>>> + compatible = "arm,cortex-a7";
>>>> + reg = <0x102>;
>>>> + cci-control-port = <&cci_control0>;
>>>> + };
>>>> + cpu@103 {
>>>> + device_type = "cpu";
>>>> + compatible = "arm,cortex-a7";
>>>> + reg = <0x103>;
>>>> + cci-control-port = <&cci_control0>;
>>>> + };
>>>> + };
>>>> +
>>>> + cmus {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + ranges;
>>>> +
>>>
>>>
>>>
>>> I don't think there is a need to group these nodes under a parent node
>>> that
>>> doesn't give any additional information, especially when the CMUs are
>>> scattered trough the whole address space, while we'd like to keep the
>>> nodes
>>> ordered by their addresses, as most platforms do.
>>>
>>
>> This is exactly the same case as "cpus". I mean, "cpus" also doesn't
>> provide
>> any common information about child cpu nodes. This looks to me as a
>> logical
>> grouping and I have implemented same thing for cmu nodes.
>> I am ok with removing this grouping Just want to understand the rational
>> behind
>> grouping cpus which seems similar to cmus.
>
>
> The "cpus" node is a defined standard node that should be present at root of
> device tree and include subnodes for all CPUs. This is a standard binding
> defined for low level code to be able to simply find nodes of all CPUs in
> the system - so they can expect that at /cpus node all the subnodes are
> subsequent CPUs.
>
>
>> Similarly "soc" is just a logical entity used to group SoC elements which
>> looks
>> optional to me. What are we achieving with this? Please help me in
>> understanding
>> this better.
>
>
> Also "soc" has a slightly wider meaning. It is a node grouping all nodes
> from a single address space - the node specifies #address-cells and
> #size-cells of this address space and all the devices under this
> "simple-bus" can be accessed using addresses in this format. In addition, it
> separates board-level devices from generic SoC devices.
>
> Now, in case of "cmus", the only purpose is to group all CMU nodes together
> and, while this improves readability a bit, it doesn't make the DT better
> express the hardware topology, because the CMUs in the hardware are in fact
> scattered through the whole address space, not under a contiguous block of
> it, as the grouping would suggest.
>
> Best regards,
> Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
@ 2014-02-14 3:24 ` Rahul Sharma
0 siblings, 0 replies; 20+ messages in thread
From: Rahul Sharma @ 2014-02-14 3:24 UTC (permalink / raw)
To: linux-arm-kernel
Thanks Tomasz,
I will add these changes to v3.
Regards,
Rahul Sharma.
On 11 February 2014 15:34, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Hi Rahul,
>
>
> On 11.02.2014 06:22, Rahul Sharma wrote:
>>
>> Hi Tomasz,
>>
>> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
>>>
>>> Hi Rahul, Pankaj, Arun,
>>>
>>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>>>
>>> I think it's good time to stop accepting DTS files like this and force
>>> new
>>> ones to use the proper structure with soc node, labels for every node and
>>> node references.
>>
>>
>> I am unable to find information on SoC node and grouping inside SoC node.
>> Please
>> share some pointers.
>
>
> Well, there is not much information needed about this. Basically all the
> devices built into the SoC should be listed under respective bus nodes or a
> single soc node, instead of root level. Such node should be a "simple-bus"
> and just group the components together to separate board-specific devices
> (which are still at root level) from SoC devices.
>
> Even though it might seem useless, it improves DT readability a bit and
> still most of the platforms use this approach, so for consistency, Exynos
> should use too.
>
> Just for reference, back in April 2013, in his review of S3C64xx DT series
> [1], Rob Herring requested that we don't submit any new device trees using
> flat approach and start using bus hierarchy.
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
>
>
>>>
>>>> + spi0_bus: spi0-bus {
>>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>>>> "gpa2-3";
>>>
>>>
>>>
>>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>>>
>>
>> I should align SPI1 with SPI0.
>>
>
> Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI,
> SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to
> the fact that the controller can only support one dedicated chip select and
> with direct GPIO control you can have more.
>
> What is the fourth pin here?
>
>
>>>
>>>> + cpu at 1 {
>>>> + device_type = "cpu";
>>>> + compatible = "arm,cortex-a15";
>>>> + reg = <1>;
>>>> + cci-control-port = <&cci_control1>;
>>>> + };
>>>> + cpu at 100 {
>>>> + device_type = "cpu";
>>>> + compatible = "arm,cortex-a7";
>>>> + reg = <0x100>;
>>>> + cci-control-port = <&cci_control0>;
>>>> + };
>>>> + cpu at 101 {
>>>> + device_type = "cpu";
>>>> + compatible = "arm,cortex-a7";
>>>> + reg = <0x101>;
>>>> + cci-control-port = <&cci_control0>;
>>>> + };
>>>> + cpu at 102 {
>>>> + device_type = "cpu";
>>>> + compatible = "arm,cortex-a7";
>>>> + reg = <0x102>;
>>>> + cci-control-port = <&cci_control0>;
>>>> + };
>>>> + cpu at 103 {
>>>> + device_type = "cpu";
>>>> + compatible = "arm,cortex-a7";
>>>> + reg = <0x103>;
>>>> + cci-control-port = <&cci_control0>;
>>>> + };
>>>> + };
>>>> +
>>>> + cmus {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + ranges;
>>>> +
>>>
>>>
>>>
>>> I don't think there is a need to group these nodes under a parent node
>>> that
>>> doesn't give any additional information, especially when the CMUs are
>>> scattered trough the whole address space, while we'd like to keep the
>>> nodes
>>> ordered by their addresses, as most platforms do.
>>>
>>
>> This is exactly the same case as "cpus". I mean, "cpus" also doesn't
>> provide
>> any common information about child cpu nodes. This looks to me as a
>> logical
>> grouping and I have implemented same thing for cmu nodes.
>> I am ok with removing this grouping Just want to understand the rational
>> behind
>> grouping cpus which seems similar to cmus.
>
>
> The "cpus" node is a defined standard node that should be present at root of
> device tree and include subnodes for all CPUs. This is a standard binding
> defined for low level code to be able to simply find nodes of all CPUs in
> the system - so they can expect that at /cpus node all the subnodes are
> subsequent CPUs.
>
>
>> Similarly "soc" is just a logical entity used to group SoC elements which
>> looks
>> optional to me. What are we achieving with this? Please help me in
>> understanding
>> this better.
>
>
> Also "soc" has a slightly wider meaning. It is a node grouping all nodes
> from a single address space - the node specifies #address-cells and
> #size-cells of this address space and all the devices under this
> "simple-bus" can be accessed using addresses in this format. In addition, it
> separates board-level devices from generic SoC devices.
>
> Now, in case of "cmus", the only purpose is to group all CMU nodes together
> and, while this improves readability a bit, it doesn't make the DT better
> express the hardware topology, because the CMUs in the hardware are in fact
> scattered through the whole address space, not under a contiguous block of
> it, as the grouping would suggest.
>
> Best regards,
> Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
2014-02-14 3:24 ` Rahul Sharma
@ 2014-02-14 11:28 ` Rahul Sharma
-1 siblings, 0 replies; 20+ messages in thread
From: Rahul Sharma @ 2014-02-14 11:28 UTC (permalink / raw)
To: Tomasz Figa
Cc: Tomasz Figa, Rahul Sharma, linux-samsung-soc, Kukjin Kim,
sunil joshi, devicetree, linux-arm-kernel, Rob Herring,
Mark Rutland, Grant Likely, Ian Campbell, Pawel Moll, Kumar Gala
On 14 February 2014 08:54, Rahul Sharma <r.sh.open@gmail.com> wrote:
> Thanks Tomasz,
>
> I will add these changes to v3.
>
> Regards,
> Rahul Sharma.
>
> On 11 February 2014 15:34, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>> Hi Rahul,
>>
>>
>> On 11.02.2014 06:22, Rahul Sharma wrote:
>>>
>>> Hi Tomasz,
>>>
>>> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
>>>>
>>>> Hi Rahul, Pankaj, Arun,
>>>>
>>>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>>>>
>>>> I think it's good time to stop accepting DTS files like this and force
>>>> new
>>>> ones to use the proper structure with soc node, labels for every node and
>>>> node references.
>>>
>>>
>>> I am unable to find information on SoC node and grouping inside SoC node.
>>> Please
>>> share some pointers.
>>
>>
>> Well, there is not much information needed about this. Basically all the
>> devices built into the SoC should be listed under respective bus nodes or a
>> single soc node, instead of root level. Such node should be a "simple-bus"
>> and just group the components together to separate board-specific devices
>> (which are still at root level) from SoC devices.
>>
>> Even though it might seem useless, it improves DT readability a bit and
>> still most of the platforms use this approach, so for consistency, Exynos
>> should use too.
>>
>> Just for reference, back in April 2013, in his review of S3C64xx DT series
>> [1], Rob Herring requested that we don't submit any new device trees using
>> flat approach and start using bus hierarchy.
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
>>
>>
>>>>
>>>>> + spi0_bus: spi0-bus {
>>>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>>>>> "gpa2-3";
>>>>
>>>>
>>>>
>>>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>>>>
>>>
>>> I should align SPI1 with SPI0.
>>>
>>
>> Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI,
>> SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to
>> the fact that the controller can only support one dedicated chip select and
>> with direct GPIO control you can have more.
>>
>> What is the fourth pin here?
>>
As you said, these are CLK, SS, MISO, MOSI (gpa2-0 to gpa2-3). Fourth pin is
CS. It can be defined as a simple GPIO but better to include it in the
SPI pingroup
as it belongs to there.
Regards,
Rahul Sharma.
>>
>>>>
>>>>> + cpu@1 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a15";
>>>>> + reg = <1>;
>>>>> + cci-control-port = <&cci_control1>;
>>>>> + };
>>>>> + cpu@100 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x100>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + cpu@101 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x101>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + cpu@102 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x102>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + cpu@103 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x103>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + cmus {
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <1>;
>>>>> + ranges;
>>>>> +
>>>>
>>>>
>>>>
>>>> I don't think there is a need to group these nodes under a parent node
>>>> that
>>>> doesn't give any additional information, especially when the CMUs are
>>>> scattered trough the whole address space, while we'd like to keep the
>>>> nodes
>>>> ordered by their addresses, as most platforms do.
>>>>
>>>
>>> This is exactly the same case as "cpus". I mean, "cpus" also doesn't
>>> provide
>>> any common information about child cpu nodes. This looks to me as a
>>> logical
>>> grouping and I have implemented same thing for cmu nodes.
>>> I am ok with removing this grouping Just want to understand the rational
>>> behind
>>> grouping cpus which seems similar to cmus.
>>
>>
>> The "cpus" node is a defined standard node that should be present at root of
>> device tree and include subnodes for all CPUs. This is a standard binding
>> defined for low level code to be able to simply find nodes of all CPUs in
>> the system - so they can expect that at /cpus node all the subnodes are
>> subsequent CPUs.
>>
>>
>>> Similarly "soc" is just a logical entity used to group SoC elements which
>>> looks
>>> optional to me. What are we achieving with this? Please help me in
>>> understanding
>>> this better.
>>
>>
>> Also "soc" has a slightly wider meaning. It is a node grouping all nodes
>> from a single address space - the node specifies #address-cells and
>> #size-cells of this address space and all the devices under this
>> "simple-bus" can be accessed using addresses in this format. In addition, it
>> separates board-level devices from generic SoC devices.
>>
>> Now, in case of "cmus", the only purpose is to group all CMU nodes together
>> and, while this improves readability a bit, it doesn't make the DT better
>> express the hardware topology, because the CMUs in the hardware are in fact
>> scattered through the whole address space, not under a contiguous block of
>> it, as the grouping would suggest.
>>
>> Best regards,
>> Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
@ 2014-02-14 11:28 ` Rahul Sharma
0 siblings, 0 replies; 20+ messages in thread
From: Rahul Sharma @ 2014-02-14 11:28 UTC (permalink / raw)
To: linux-arm-kernel
On 14 February 2014 08:54, Rahul Sharma <r.sh.open@gmail.com> wrote:
> Thanks Tomasz,
>
> I will add these changes to v3.
>
> Regards,
> Rahul Sharma.
>
> On 11 February 2014 15:34, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>> Hi Rahul,
>>
>>
>> On 11.02.2014 06:22, Rahul Sharma wrote:
>>>
>>> Hi Tomasz,
>>>
>>> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
>>>>
>>>> Hi Rahul, Pankaj, Arun,
>>>>
>>>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>>>>
>>>> I think it's good time to stop accepting DTS files like this and force
>>>> new
>>>> ones to use the proper structure with soc node, labels for every node and
>>>> node references.
>>>
>>>
>>> I am unable to find information on SoC node and grouping inside SoC node.
>>> Please
>>> share some pointers.
>>
>>
>> Well, there is not much information needed about this. Basically all the
>> devices built into the SoC should be listed under respective bus nodes or a
>> single soc node, instead of root level. Such node should be a "simple-bus"
>> and just group the components together to separate board-specific devices
>> (which are still at root level) from SoC devices.
>>
>> Even though it might seem useless, it improves DT readability a bit and
>> still most of the platforms use this approach, so for consistency, Exynos
>> should use too.
>>
>> Just for reference, back in April 2013, in his review of S3C64xx DT series
>> [1], Rob Herring requested that we don't submit any new device trees using
>> flat approach and start using bus hierarchy.
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
>>
>>
>>>>
>>>>> + spi0_bus: spi0-bus {
>>>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>>>>> "gpa2-3";
>>>>
>>>>
>>>>
>>>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>>>>
>>>
>>> I should align SPI1 with SPI0.
>>>
>>
>> Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI,
>> SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to
>> the fact that the controller can only support one dedicated chip select and
>> with direct GPIO control you can have more.
>>
>> What is the fourth pin here?
>>
As you said, these are CLK, SS, MISO, MOSI (gpa2-0 to gpa2-3). Fourth pin is
CS. It can be defined as a simple GPIO but better to include it in the
SPI pingroup
as it belongs to there.
Regards,
Rahul Sharma.
>>
>>>>
>>>>> + cpu at 1 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a15";
>>>>> + reg = <1>;
>>>>> + cci-control-port = <&cci_control1>;
>>>>> + };
>>>>> + cpu at 100 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x100>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + cpu at 101 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x101>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + cpu at 102 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x102>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + cpu at 103 {
>>>>> + device_type = "cpu";
>>>>> + compatible = "arm,cortex-a7";
>>>>> + reg = <0x103>;
>>>>> + cci-control-port = <&cci_control0>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + cmus {
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <1>;
>>>>> + ranges;
>>>>> +
>>>>
>>>>
>>>>
>>>> I don't think there is a need to group these nodes under a parent node
>>>> that
>>>> doesn't give any additional information, especially when the CMUs are
>>>> scattered trough the whole address space, while we'd like to keep the
>>>> nodes
>>>> ordered by their addresses, as most platforms do.
>>>>
>>>
>>> This is exactly the same case as "cpus". I mean, "cpus" also doesn't
>>> provide
>>> any common information about child cpu nodes. This looks to me as a
>>> logical
>>> grouping and I have implemented same thing for cmu nodes.
>>> I am ok with removing this grouping Just want to understand the rational
>>> behind
>>> grouping cpus which seems similar to cmus.
>>
>>
>> The "cpus" node is a defined standard node that should be present at root of
>> device tree and include subnodes for all CPUs. This is a standard binding
>> defined for low level code to be able to simply find nodes of all CPUs in
>> the system - so they can expect that at /cpus node all the subnodes are
>> subsequent CPUs.
>>
>>
>>> Similarly "soc" is just a logical entity used to group SoC elements which
>>> looks
>>> optional to me. What are we achieving with this? Please help me in
>>> understanding
>>> this better.
>>
>>
>> Also "soc" has a slightly wider meaning. It is a node grouping all nodes
>> from a single address space - the node specifies #address-cells and
>> #size-cells of this address space and all the devices under this
>> "simple-bus" can be accessed using addresses in this format. In addition, it
>> separates board-level devices from generic SoC devices.
>>
>> Now, in case of "cmus", the only purpose is to group all CMU nodes together
>> and, while this improves readability a bit, it doesn't make the DT better
>> express the hardware topology, because the CMUs in the hardware are in fact
>> scattered through the whole address space, not under a contiguous block of
>> it, as the grouping would suggest.
>>
>> Best regards,
>> Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
2014-02-14 11:28 ` Rahul Sharma
@ 2014-02-14 11:49 ` Tomasz Figa
-1 siblings, 0 replies; 20+ messages in thread
From: Tomasz Figa @ 2014-02-14 11:49 UTC (permalink / raw)
To: Rahul Sharma, Tomasz Figa
Cc: Rahul Sharma, linux-samsung-soc, Kukjin Kim, sunil joshi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland, Grant Likely, Ian Campbell, Pawel Moll, Kumar Gala
On 14.02.2014 12:28, Rahul Sharma wrote:
> On 14 February 2014 08:54, Rahul Sharma <r.sh.open-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Thanks Tomasz,
>>
>> I will add these changes to v3.
>>
>> Regards,
>> Rahul Sharma.
>>
>> On 11 February 2014 15:34, Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> Hi Rahul,
>>>
>>>
>>> On 11.02.2014 06:22, Rahul Sharma wrote:
>>>>
>>>> Hi Tomasz,
>>>>
>>>> On 6 February 2014 18:51, Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>>>>>
>>>>> Hi Rahul, Pankaj, Arun,
>>>>>
>>>>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>>>>>
>>>>> I think it's good time to stop accepting DTS files like this and force
>>>>> new
>>>>> ones to use the proper structure with soc node, labels for every node and
>>>>> node references.
>>>>
>>>>
>>>> I am unable to find information on SoC node and grouping inside SoC node.
>>>> Please
>>>> share some pointers.
>>>
>>>
>>> Well, there is not much information needed about this. Basically all the
>>> devices built into the SoC should be listed under respective bus nodes or a
>>> single soc node, instead of root level. Such node should be a "simple-bus"
>>> and just group the components together to separate board-specific devices
>>> (which are still at root level) from SoC devices.
>>>
>>> Even though it might seem useless, it improves DT readability a bit and
>>> still most of the platforms use this approach, so for consistency, Exynos
>>> should use too.
>>>
>>> Just for reference, back in April 2013, in his review of S3C64xx DT series
>>> [1], Rob Herring requested that we don't submit any new device trees using
>>> flat approach and start using bus hierarchy.
>>>
>>> [1]
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
>>>
>>>
>>>>>
>>>>>> + spi0_bus: spi0-bus {
>>>>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>>>>>> "gpa2-3";
>>>>>
>>>>>
>>>>>
>>>>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>>>>>
>>>>
>>>> I should align SPI1 with SPI0.
>>>>
>>>
>>> Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI,
>>> SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to
>>> the fact that the controller can only support one dedicated chip select and
>>> with direct GPIO control you can have more.
>>>
>>> What is the fourth pin here?
>>>
>
> As you said, these are CLK, SS, MISO, MOSI (gpa2-0 to gpa2-3). Fourth pin is
> CS. It can be defined as a simple GPIO but better to include it in the
> SPI pingroup
> as it belongs to there.
I have to disagree here.
If you define a pin in pinctrl group then it is tied to this specific
hardware function and you can't use it as GPIO.
Since it's board specific to use it as HW chip select or GPIO chip
select (the usual setup), it should not be included in this group.
Best regards,
Tomasz
--
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] 20+ messages in thread
* [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
@ 2014-02-14 11:49 ` Tomasz Figa
0 siblings, 0 replies; 20+ messages in thread
From: Tomasz Figa @ 2014-02-14 11:49 UTC (permalink / raw)
To: linux-arm-kernel
On 14.02.2014 12:28, Rahul Sharma wrote:
> On 14 February 2014 08:54, Rahul Sharma <r.sh.open@gmail.com> wrote:
>> Thanks Tomasz,
>>
>> I will add these changes to v3.
>>
>> Regards,
>> Rahul Sharma.
>>
>> On 11 February 2014 15:34, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>>> Hi Rahul,
>>>
>>>
>>> On 11.02.2014 06:22, Rahul Sharma wrote:
>>>>
>>>> Hi Tomasz,
>>>>
>>>> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
>>>>>
>>>>> Hi Rahul, Pankaj, Arun,
>>>>>
>>>>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>>>>>
>>>>> I think it's good time to stop accepting DTS files like this and force
>>>>> new
>>>>> ones to use the proper structure with soc node, labels for every node and
>>>>> node references.
>>>>
>>>>
>>>> I am unable to find information on SoC node and grouping inside SoC node.
>>>> Please
>>>> share some pointers.
>>>
>>>
>>> Well, there is not much information needed about this. Basically all the
>>> devices built into the SoC should be listed under respective bus nodes or a
>>> single soc node, instead of root level. Such node should be a "simple-bus"
>>> and just group the components together to separate board-specific devices
>>> (which are still at root level) from SoC devices.
>>>
>>> Even though it might seem useless, it improves DT readability a bit and
>>> still most of the platforms use this approach, so for consistency, Exynos
>>> should use too.
>>>
>>> Just for reference, back in April 2013, in his review of S3C64xx DT series
>>> [1], Rob Herring requested that we don't submit any new device trees using
>>> flat approach and start using bus hierarchy.
>>>
>>> [1]
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html
>>>
>>>
>>>>>
>>>>>> + spi0_bus: spi0-bus {
>>>>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>>>>>> "gpa2-3";
>>>>>
>>>>>
>>>>>
>>>>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>>>>>
>>>>
>>>> I should align SPI1 with SPI0.
>>>>
>>>
>>> Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI,
>>> SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to
>>> the fact that the controller can only support one dedicated chip select and
>>> with direct GPIO control you can have more.
>>>
>>> What is the fourth pin here?
>>>
>
> As you said, these are CLK, SS, MISO, MOSI (gpa2-0 to gpa2-3). Fourth pin is
> CS. It can be defined as a simple GPIO but better to include it in the
> SPI pingroup
> as it belongs to there.
I have to disagree here.
If you define a pin in pinctrl group then it is tied to this specific
hardware function and you can't use it as GPIO.
Since it's board specific to use it as HW chip select or GPIO chip
select (the usual setup), it should not be included in this group.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v2 2/3] ARM: dts: add dts files for exynos5260 SoC
2014-02-05 6:17 [PATCH v2 " Rahul Sharma
@ 2014-02-05 6:17 ` Rahul Sharma
0 siblings, 0 replies; 20+ messages in thread
From: Rahul Sharma @ 2014-02-05 6:17 UTC (permalink / raw)
To: linux-samsung-soc; +Cc: kgene.kim, tomasz.figa, joshi, r.sh.open, Rahul Sharma
The patch adds the dts files for exynos5260.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
---
arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572 +++++++++++++++++++++++++++++
arch/arm/boot/dts/exynos5260.dtsi | 317 ++++++++++++++++
2 files changed, 889 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
new file mode 100644
index 0000000..3f2c5c4
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
@@ -0,0 +1,572 @@
+/*
+ * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+ pinctrl@11600000 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb0: gpb0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb1: gpb1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb2: gpb2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb3: gpb3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb4: gpb4 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb5: gpb5 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd2: gpd2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpe0: gpe0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpe1: gpe1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf1: gpf1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpk0: gpk0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpx0: gpx0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpx1: gpx1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpx2: gpx2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpx3: gpx3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ uart0_data: uart0-data {
+ samsung,pins = "gpa0-0", "gpa0-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart0_fctl: uart0-fctl {
+ samsung,pins = "gpa0-2", "gpa0-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_data: uart1-data {
+ samsung,pins = "gpa1-0", "gpa1-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_fctl: uart1-fctl {
+ samsung,pins = "gpa1-2", "gpa1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart2_data: uart2-data {
+ samsung,pins = "gpa1-4", "gpa1-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ spi0_bus: spi0-bus {
+ samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", "gpa2-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ spi1_bus: spi1-bus {
+ samsung,pins = "gpa2-5", "gpa2-6", "gpa2-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ usb3_vbus0_en: usb3-vbus0-en {
+ samsung,pins = "gpa2-4";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2s1_bus: i2s1-bus {
+ samsung,pins = "gpb0-0", "gpb0-1", "gpb0-2", "gpb0-3",
+ "gpb0-4";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ pcm1_bus: pcm1-bus {
+ samsung,pins = "gpb0-0", "gpb0-1", "gpb0-2", "gpb0-3",
+ "gpb0-4";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ spdif1_bus: spdif1-bus {
+ samsung,pins = "gpb0-0", "gpb0-1", "gpb0-2";
+ samsung,pin-function = <4>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ spi2_bus: spi2-bus {
+ samsung,pins = "gpb1-0", "gpb1-1", "gpb1-2", "gpb1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c0_hs_bus: i2c0-hs-bus {
+ samsung,pins = "gpb3-0", "gpb3-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c1_hs_bus: i2c1-hs-bus {
+ samsung,pins = "gpb3-2", "gpb3-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c2_hs_bus: i2c2-hs-bus {
+ samsung,pins = "gpb3-4", "gpb3-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c3_hs_bus: i2c3-hs-bus {
+ samsung,pins = "gpb3-6", "gpb3-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c4_bus: i2c4-bus {
+ samsung,pins = "gpb4-0", "gpb4-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c5_bus: i2c5-bus {
+ samsung,pins = "gpb4-2", "gpb4-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c6_bus: i2c6-bus {
+ samsung,pins = "gpb4-4", "gpb4-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c7_bus: i2c7-bus {
+ samsung,pins = "gpb4-6", "gpb4-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c8_bus: i2c8-bus {
+ samsung,pins = "gpb5-0", "gpb5-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c9_bus: i2c9-bus {
+ samsung,pins = "gpb5-2", "gpb5-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c10_bus: i2c10-bus {
+ samsung,pins = "gpb5-4", "gpb5-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c11_bus: i2c11-bus {
+ samsung,pins = "gpb5-6", "gpb5-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_gpio_a: cam-gpio-a {
+ samsung,pins = "gpe0-0", "gpe0-1", "gpe0-2", "gpe0-3",
+ "gpe0-4", "gpe0-5", "gpe0-6", "gpe0-7",
+ "gpe1-0", "gpe1-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_gpio_b: cam-gpio-b {
+ samsung,pins = "gpf0-0", "gpf0-1", "gpf0-2", "gpf0-3",
+ "gpf1-0", "gpf1-1", "gpf1-2", "gpf1-3";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_i2c1_bus: cam-i2c1-bus {
+ samsung,pins = "gpf0-2", "gpf0-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_i2c0_bus: cam-i2c0-bus {
+ samsung,pins = "gpf0-0", "gpf0-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_spi0_bus: cam-spi0-bus {
+ samsung,pins = "gpf1-0", "gpf1-1", "gpf1-2", "gpf1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_spi1_bus: cam-spi1-bus {
+ samsung,pins = "gpf1-4", "gpf1-5", "gpf1-6", "gpf1-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+ };
+
+ pinctrl@12290000 {
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc2: gpc2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc3: gpc3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc4: gpc4 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ sd0_clk: sd0-clk {
+ samsung,pins = "gpc0-0";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd0_cmd: sd0-cmd {
+ samsung,pins = "gpc0-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd0_bus1: sd0-bus-width1 {
+ samsung,pins = "gpc0-2";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd0_bus4: sd0-bus-width4 {
+ samsung,pins = "gpc0-3", "gpc0-4", "gpc0-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd0_bus8: sd0-bus-width8 {
+ samsung,pins = "gpc3-0", "gpc3-1", "gpc3-2", "gpc3-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd0_rdqs: sd0-rdqs {
+ samsung,pins = "gpc0-6";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd1_clk: sd1-clk {
+ samsung,pins = "gpc1-0";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd1_cmd: sd1-cmd {
+ samsung,pins = "gpc1-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd1_bus1: sd1-bus-width1 {
+ samsung,pins = "gpc1-2";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd1_bus4: sd1-bus-width4 {
+ samsung,pins = "gpc1-3", "gpc1-4", "gpc1-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd1_bus8: sd1-bus-width8 {
+ samsung,pins = "gpc4-0", "gpc4-1", "gpc4-2", "gpc4-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd2_clk: sd2-clk {
+ samsung,pins = "gpc2-0";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd2_cmd: sd2-cmd {
+ samsung,pins = "gpc2-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd2_cd: sd2-cd {
+ samsung,pins = "gpc2-2";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd2_bus1: sd2-bus-width1 {
+ samsung,pins = "gpc2-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+
+ sd2_bus4: sd2-bus-width4 {
+ samsung,pins = "gpc2-4", "gpc2-5", "gpc2-6";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+ };
+
+ pinctrl@128B0000 {
+ gpz0: gpz0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpz1: gpz1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
new file mode 100644
index 0000000..32a95c7
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -0,0 +1,317 @@
+/*
+ * SAMSUNG EXYNOS5260 SoC device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include "skeleton.dtsi"
+#include "exynos5260-pinctrl.dtsi"
+
+#include <dt-bindings/clk/exynos5260-clk.h>
+
+/ {
+ compatible = "samsung,exynos5260";
+ interrupt-parent = <&gic>;
+
+ aliases {
+ pinctrl0 = &pinctrl_0;
+ pinctrl1 = &pinctrl_1;
+ pinctrl2 = &pinctrl_2;
+ };
+
+ chipid@10000000 {
+ compatible = "samsung,exynos4210-chipid";
+ reg = <0x10000000 0x100>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ cci-control-port = <&cci_control1>;
+ };
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ cci-control-port = <&cci_control1>;
+ };
+ cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x100>;
+ cci-control-port = <&cci_control0>;
+ };
+ cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x101>;
+ cci-control-port = <&cci_control0>;
+ };
+ cpu@102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x102>;
+ cci-control-port = <&cci_control0>;
+ };
+ cpu@103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x103>;
+ cci-control-port = <&cci_control0>;
+ };
+ };
+
+ cmus {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ cmu_top: clock-controller@10010000 {
+ compatible = "exynos5260-cmu-top", "samsung,exynos5260-clock";
+ reg = <0x10010000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_peri: clock-controller@10200000 {
+ compatible = "exynos5260-cmu-peri", "samsung,exynos5260-clock";
+ reg = <0x10200000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_egl: clock-controller@10600000 {
+ compatible = "exynos5260-cmu-egl", "samsung,exynos5260-clock";
+ reg = <0x10600000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_kfc: clock-controller@10700000 {
+ compatible = "exynos5260-cmu-kfc", "samsung,exynos5260-clock";
+ reg = <0x10700000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_g2d: clock-controller@10A00000 {
+ compatible = "exynos5260-cmu-g2d", "samsung,exynos5260-clock";
+ reg = <0x10A00000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_mif: clock-controller@10CE0000 {
+ compatible = "exynos5260-cmu-mif", "samsung,exynos5260-clock";
+ reg = <0x10CE0000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_mfc: clock-controller@11090000 {
+ compatible = "exynos5260-cmu-mfc", "samsung,exynos5260-clock";
+ reg = <0x11090000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_g3d: clock-controller@11830000 {
+ compatible = "exynos5260-cmu-g3d", "samsung,exynos5260-clock";
+ reg = <0x11830000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_fsys: clock-controller@122E0000 {
+ compatible = "exynos5260-cmu-fsys", "samsung,exynos5260-clock";
+ reg = <0x122E0000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_aud: clock-controller@128C0000 {
+ compatible = "exynos5260-cmu-aud", "samsung,exynos5260-clock";
+ reg = <0x128C0000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_isp: clock-controller@133C0000 {
+ compatible = "exynos5260-cmu-isp", "samsung,exynos5260-clock";
+ reg = <0x133C0000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_gscl: clock-controller@13F00000 {
+ compatible = "exynos5260-cmu-gscl", "samsung,exynos5260-clock";
+ reg = <0x13F00000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ cmu_disp: clock-controller@14550000 {
+ compatible = "exynos5260-cmu-disp", "samsung,exynos5260-clock";
+ reg = <0x14550000 0x10000>;
+ #clock-cells = <1>;
+ };
+ };
+
+ gic: interrupt-controller@10481000 {
+ compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-controller;
+ reg = <0x10481000 0x1000>,
+ <0x10482000 0x1000>,
+ <0x10484000 0x2000>,
+ <0x10486000 0x2000>;
+ interrupts = <1 9 0xf04>;
+ };
+
+ mct@100B0000 {
+ compatible = "samsung,exynos4210-mct";
+ reg = <0x100B0000 0x1000>;
+ interrupt-controller;
+ #interrups-cells = <1>;
+ interrupt-parent = <&mct_map>;
+ interrupts = <0>, <1>, <2>, <3>,
+ <4>, <5>, <6>, <7>,
+ <8>, <9>, <10>, <11>;
+ clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>;
+ clock-names = "fin_pll", "mct";
+
+ mct_map: mct-map {
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &gic 0 104 0>,
+ <1 &gic 0 105 0>,
+ <2 &gic 0 106 0>,
+ <3 &gic 0 107 0>,
+ <4 &gic 0 122 0>,
+ <5 &gic 0 123 0>,
+ <6 &gic 0 124 0>,
+ <7 &gic 0 125 0>,
+ <8 &gic 0 126 0>,
+ <9 &gic 0 127 0>,
+ <10 &gic 0 128 0>,
+ <11 &gic 0 129 0>;
+ };
+ };
+
+ cci@10F00000 {
+ compatible = "arm,cci-400";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x10F00000 0x1000>;
+ ranges = <0x0 0x10F00000 0x6000>;
+
+ cci_control0: slave-if@4000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x4000 0x1000>;
+ };
+
+ cci_control1: slave-if@5000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x5000 0x1000>;
+ };
+ };
+
+ pinctrl_0: pinctrl@11600000 {
+ compatible = "samsung,exynos5260-pinctrl";
+ reg = <0x11600000 0x1000>;
+ interrupts = <0 79 0>;
+
+ wakeup-interrupt-controller {
+ compatible = "samsung,exynos4210-wakeup-eint";
+ interrupt-parent = <&gic>;
+ interrupts = <0 32 0>;
+ };
+ };
+
+ pinctrl_1: pinctrl@12290000 {
+ compatible = "samsung,exynos5260-pinctrl";
+ reg = <0x12290000 0x1000>;
+ interrupts = <0 157 0>;
+ };
+
+ pinctrl_2: pinctrl@128B0000 {
+ compatible = "samsung,exynos5260-pinctrl";
+ reg = <0x128B0000 0x1000>;
+ interrupts = <0 243 0>;
+ };
+
+ serial@12C00000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12C00000 0x100>;
+ interrupts = <0 146 0>;
+ clocks = <&cmu_peri PERI_CLK_UART0>, <&cmu_peri PERI_SCLK_UART0>;
+ clock-names = "uart", "clk_uart_baud0";
+ status = "disabled";
+ };
+
+ serial@12C10000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12C10000 0x100>;
+ interrupts = <0 147 0>;
+ clocks = <&cmu_peri PERI_CLK_UART1>, <&cmu_peri PERI_SCLK_UART1>;
+ clock-names = "uart", "clk_uart_baud0";
+ status = "disabled";
+ };
+
+ serial@12C20000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12C20000 0x100>;
+ interrupts = <0 148 0>;
+ clocks = <&cmu_peri PERI_CLK_UART2>, <&cmu_peri PERI_SCLK_UART2>;
+ clock-names = "uart", "clk_uart_baud0";
+ status = "disabled";
+ };
+
+ serial@12860000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12860000 0x100>;
+ interrupts = <0 145 0>;
+ clocks = <&cmu_aud AUD_CLK_AUD_UART>, <&cmu_aud AUD_SCLK_AUD_UART>;
+ clock-names = "uart", "clk_uart_baud0";
+ status = "disabled";
+ };
+
+ mmc_0: mmc0@12140000 {
+ compatible = "samsung,exynos5250-dw-mshc";
+ reg = <0x12140000 0x2000>;
+ interrupts = <0 156 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top TOP_SCLK_MMC0>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
+ mmc_1: mmc1@12150000 {
+ compatible = "samsung,exynos5250-dw-mshc";
+ reg = <0x12150000 0x2000>;
+ interrupts = <0 158 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cmu_fsys FSYS_CLK_MMC1>, <&cmu_top TOP_SCLK_MMC1>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
+ mmc_2: mmc2@12160000 {
+ compatible = "samsung,exynos5250-dw-mshc";
+ reg = <0x12160000 0x2000>;
+ interrupts = <0 159 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cmu_fsys FSYS_CLK_MMC2>, <&cmu_top TOP_SCLK_MMC2>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-02-14 11:49 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-05 5:16 [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC Rahul Sharma
2014-02-05 5:16 ` [PATCH V2 1/3] ARM: EXYNOS: initial board " Rahul Sharma
2014-02-05 21:55 ` Olof Johansson
2014-02-05 5:16 ` [PATCH V2 2/3] ARM: dts: add dts files " Rahul Sharma
2014-02-06 13:21 ` Tomasz Figa
2014-02-06 13:21 ` Tomasz Figa
2014-02-11 5:22 ` Rahul Sharma
2014-02-11 5:22 ` Rahul Sharma
2014-02-11 10:04 ` Tomasz Figa
2014-02-11 10:04 ` Tomasz Figa
2014-02-14 3:24 ` Rahul Sharma
2014-02-14 3:24 ` Rahul Sharma
2014-02-14 11:28 ` Rahul Sharma
2014-02-14 11:28 ` Rahul Sharma
[not found] ` <CAPdUM4Pr7UC3wzYMsO+sYQHRDGixSNsR3XQuHBomsi-H-dfOZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-02-14 11:49 ` Tomasz Figa
2014-02-14 11:49 ` Tomasz Figa
2014-02-05 5:16 ` [PATCH V2 3/3] ARM: dts: add dts files for xyref5260 board Rahul Sharma
2014-02-05 5:31 ` [PATCH V2 0/3] exynos: arch: add support for exynos5260 SoC Jingoo Han
2014-02-05 6:17 ` Rahul Sharma
2014-02-05 6:17 [PATCH v2 " Rahul Sharma
2014-02-05 6:17 ` [PATCH v2 2/3] ARM: dts: add dts files " Rahul Sharma
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.