* [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC @ 2014-08-27 9:44 ` Naveen Krishna Chatradhi 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Chatradhi @ 2014-08-27 9:44 UTC (permalink / raw) To: catalin.marinas Cc: naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. Exynos7 is a System-On-Chip (SoC) that is based on 64-bit ARMv8 RISC processor. This patchset includes the following: - Support for pinctrl on Exynos7 - Support for clock control on Exynos7 using common clk framework - DTS and DTSI file addition for Exynos7 based Espresso board - Support for serial driver on Exynos7 - Support for HSI2C driver on Exynos7 - Support for Watchdog driver on Exynos7 NOTE: We tested these patches with the "arm64: dts: add <dt-bindings/> symlink" change posted @ http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224629.html The following patches are tested based on Kgene's for-next tree. https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next Alim Akhtar (2): arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support tty/serial: samsung: add support for exynos7 Naveen Krishna Chatradhi (12): clk: samsung: add support for 145xx and 1460x PLLs clk: samsung: Factor out the common code to clk.c clk: samsung: Add fixed_factor_clocks field to struct exynos_cmu_info clk: samsung: Add clock description for basic CMU blocks pinctrl: exynos: Add driver data for Exynos7 pinctrl: samsung: use CONFIG_PINCTRL_SAMSUNG symbol in makefile i2c: exynos: add support for HSI2C module on Exynos7 i2c: exynos5: Add Kconfig dependencies watchdog: s3c2410_wdt: Add support for Watchdog device on Exynos7 arm64: dts: add pinctrl support to EXYNOS7 arm64: dts: Add initial device tree support for EXYNOS7 arm64: dts: add Exynos7 based Espresso board dts file .../devicetree/bindings/clock/exynos7-clock.txt | 209 +++ .../devicetree/bindings/i2c/i2c-exynos5.txt | 2 + .../bindings/pinctrl/samsung-pinctrl.txt | 1 + .../devicetree/bindings/watchdog/samsung-wdt.txt | 1 + arch/arm64/Kconfig | 17 + arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/exynos7-espresso.dts | 69 + arch/arm64/boot/dts/exynos7-pinctrl.dtsi | 691 +++++++ arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++ drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos5260.c | 181 +- drivers/clk/samsung/clk-exynos7.c | 1929 ++++++++++++++++++++ drivers/clk/samsung/clk-pll.c | 50 +- drivers/clk/samsung/clk-pll.h | 4 + drivers/clk/samsung/clk.c | 104 ++ drivers/clk/samsung/clk.h | 37 + drivers/i2c/busses/Kconfig | 2 +- drivers/i2c/busses/i2c-exynos5.c | 71 +- drivers/pinctrl/Makefile | 2 +- drivers/pinctrl/samsung/Kconfig | 2 +- drivers/pinctrl/samsung/pinctrl-exynos.c | 145 ++ drivers/pinctrl/samsung/pinctrl-samsung.c | 2 + drivers/pinctrl/samsung/pinctrl-samsung.h | 1 + drivers/tty/serial/Kconfig | 6 +- drivers/tty/serial/samsung.c | 2 +- drivers/watchdog/s3c2410_wdt.c | 11 + include/dt-bindings/clock/exynos7-clk.h | 236 +++ 27 files changed, 4151 insertions(+), 179 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/exynos7-clock.txt create mode 100644 arch/arm64/boot/dts/exynos7-espresso.dts create mode 100644 arch/arm64/boot/dts/exynos7-pinctrl.dtsi create mode 100644 arch/arm64/boot/dts/exynos7.dtsi create mode 100644 drivers/clk/samsung/clk-exynos7.c create mode 100644 include/dt-bindings/clock/exynos7-clk.h -- 1.7.9.5 ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC @ 2014-08-27 9:44 ` Naveen Krishna Chatradhi 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Chatradhi @ 2014-08-27 9:44 UTC (permalink / raw) To: linux-arm-kernel This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. Exynos7 is a System-On-Chip (SoC) that is based on 64-bit ARMv8 RISC processor. This patchset includes the following: - Support for pinctrl on Exynos7 - Support for clock control on Exynos7 using common clk framework - DTS and DTSI file addition for Exynos7 based Espresso board - Support for serial driver on Exynos7 - Support for HSI2C driver on Exynos7 - Support for Watchdog driver on Exynos7 NOTE: We tested these patches with the "arm64: dts: add <dt-bindings/> symlink" change posted @ http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224629.html The following patches are tested based on Kgene's for-next tree. https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next Alim Akhtar (2): arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support tty/serial: samsung: add support for exynos7 Naveen Krishna Chatradhi (12): clk: samsung: add support for 145xx and 1460x PLLs clk: samsung: Factor out the common code to clk.c clk: samsung: Add fixed_factor_clocks field to struct exynos_cmu_info clk: samsung: Add clock description for basic CMU blocks pinctrl: exynos: Add driver data for Exynos7 pinctrl: samsung: use CONFIG_PINCTRL_SAMSUNG symbol in makefile i2c: exynos: add support for HSI2C module on Exynos7 i2c: exynos5: Add Kconfig dependencies watchdog: s3c2410_wdt: Add support for Watchdog device on Exynos7 arm64: dts: add pinctrl support to EXYNOS7 arm64: dts: Add initial device tree support for EXYNOS7 arm64: dts: add Exynos7 based Espresso board dts file .../devicetree/bindings/clock/exynos7-clock.txt | 209 +++ .../devicetree/bindings/i2c/i2c-exynos5.txt | 2 + .../bindings/pinctrl/samsung-pinctrl.txt | 1 + .../devicetree/bindings/watchdog/samsung-wdt.txt | 1 + arch/arm64/Kconfig | 17 + arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/exynos7-espresso.dts | 69 + arch/arm64/boot/dts/exynos7-pinctrl.dtsi | 691 +++++++ arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++ drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos5260.c | 181 +- drivers/clk/samsung/clk-exynos7.c | 1929 ++++++++++++++++++++ drivers/clk/samsung/clk-pll.c | 50 +- drivers/clk/samsung/clk-pll.h | 4 + drivers/clk/samsung/clk.c | 104 ++ drivers/clk/samsung/clk.h | 37 + drivers/i2c/busses/Kconfig | 2 +- drivers/i2c/busses/i2c-exynos5.c | 71 +- drivers/pinctrl/Makefile | 2 +- drivers/pinctrl/samsung/Kconfig | 2 +- drivers/pinctrl/samsung/pinctrl-exynos.c | 145 ++ drivers/pinctrl/samsung/pinctrl-samsung.c | 2 + drivers/pinctrl/samsung/pinctrl-samsung.h | 1 + drivers/tty/serial/Kconfig | 6 +- drivers/tty/serial/samsung.c | 2 +- drivers/watchdog/s3c2410_wdt.c | 11 + include/dt-bindings/clock/exynos7-clk.h | 236 +++ 27 files changed, 4151 insertions(+), 179 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/exynos7-clock.txt create mode 100644 arch/arm64/boot/dts/exynos7-espresso.dts create mode 100644 arch/arm64/boot/dts/exynos7-pinctrl.dtsi create mode 100644 arch/arm64/boot/dts/exynos7.dtsi create mode 100644 drivers/clk/samsung/clk-exynos7.c create mode 100644 include/dt-bindings/clock/exynos7-clk.h -- 1.7.9.5 ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 10/14] arm64: dts: add pinctrl support to EXYNOS7 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-27 9:44 ` Naveen Krishna Chatradhi -1 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Chatradhi @ 2014-08-27 9:44 UTC (permalink / raw) To: catalin.marinas Cc: naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Add the required pin configuration support to EXYNOS7 using pinctrl interface. Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Cc: Thomas Abraham <thomas.ab@samsung.com> Cc: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/boot/dts/exynos7-pinctrl.dtsi | 691 ++++++++++++++++++++++++++++++ 1 file changed, 691 insertions(+) create mode 100644 arch/arm64/boot/dts/exynos7-pinctrl.dtsi diff --git a/arch/arm64/boot/dts/exynos7-pinctrl.dtsi b/arch/arm64/boot/dts/exynos7-pinctrl.dtsi new file mode 100644 index 0000000..96e9d99 --- /dev/null +++ b/arch/arm64/boot/dts/exynos7-pinctrl.dtsi @@ -0,0 +1,691 @@ +/* + * Samsung's Exynos7 SoC pin-mux and pin-config device tree source + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Samsung's Exynos7 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. +*/ + +/ { + /* ALIVE block @10580000 */ + pinctrl@10580000 { + gpa0: gpa0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&gic>; + interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, + <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>; + }; + + gpa1: gpa1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpa2: gpa2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpa3: gpa3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + + /* AUD block @114B0000 */ + pinctrl@114B0000 { + gpz0: gpz0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpz1: gpz1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + + /* BUS0 block @13470000 */ + pinctrl@13470000 { + gpb0: gpb0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + 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>; + }; + + 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>; + }; + + gpd4: gpd4 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd5: gpd5 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd6: gpd6 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd7: gpd7 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd8: gpd8 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpg0: gpg0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpg3: gpg3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + /* HSI2C Sensor 0 */ + hs_i2c10_bus: hs-i2c10-bus { + samsung,pins = "gpb0-1", "gpb0-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + /* HSI2C Sensor 1 */ + hs_i2c11_bus: hs-i2c11-bus { + samsung,pins = "gpb0-3", "gpb0-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + hs_i2c2_bus: hs-i2c2-bus { + samsung,pins = "gpd0-3", "gpd0-2"; + samsung,pin-function = <3>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + uart0_data: uart0-data { + samsung,pins = "gpd0-0", "gpd0-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + uart0_fctl: uart0-fctl { + samsung,pins = "gpd0-2", "gpd0-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + uart2_data: uart2-data { + samsung,pins = "gpd1-4", "gpd1-5"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + hs_i2c3_bus: hs-i2c3-bus { + samsung,pins = "gpd1-3", "gpd1-2"; + samsung,pin-function = <3>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + uart1_data: uart1-data { + samsung,pins = "gpd1-0", "gpd1-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + uart1_fctl: uart1-fctl { + samsung,pins = "gpd1-2", "gpd1-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + hs_i2c0_bus: hs-i2c0-bus { + samsung,pins = "gpd2-1", "gpd2-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + hs_i2c1_bus: hs-i2c1-bus { + samsung,pins = "gpd2-3", "gpd2-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + hs_i2c9_bus: hs-i2c9-bus { + samsung,pins = "gpd2-7", "gpd2-6"; + samsung,pin-function = <3>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + hs_i2c8_bus: hs-i2c8-bus { + samsung,pins = "gpd5-3", "gpd5-2"; + samsung,pin-function = <3>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + uart3_data: uart3-data { + samsung,pins = "gpd5-0", "gpd5-1"; + samsung,pin-function = <3>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + disp_teson: disp_teson { + samsung,pins = "gpg0-1"; + samsung,pin-function = <2>; + }; + + disp_tesoff: disp_tesoff { + samsung,pins = "gpg0-1"; + samsung,pin-function = <0>; + }; + + spi2_bus: spi2-bus { + samsung,pins = "gpd5-0", "gpd5-1", "gpd5-2", "gpd5-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + spi1_bus: spi1-bus { + samsung,pins = "gpd6-2", "gpd6-3", "gpd6-4", "gpd6-5"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + spi0_bus: spi0-bus { + samsung,pins = "gpd8-0", "gpd8-1", "gpd6-0", "gpd6-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + /* HSI2C sensor 2 */ + hs_i2c4_bus: hs-i2c4-bus { + samsung,pins = "gpg3-1", "gpg3-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + /* HSI2C sensor 3 */ + hs_i2c5_bus: hs-i2c5-bus { + samsung,pins = "gpg3-3", "gpg3-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + }; + + /* BUS1 block @14870000 */ + pinctrl@14870000 { + etc1: etc1 { + 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>; + }; + + gpf2: gpf2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpf3: gpf3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpf4: gpf4 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpf5: gpf5 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpg1: gpg1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpg2: gpg2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gph1: gph1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpv6: gpv6 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + + /* NFC block @14CD0000 */ + pinctrl@14CD0000 { + gpj0: gpj0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + hs_i2c6_bus: hs-i2c6-bus { + samsung,pins = "gpj0-1", "gpj0-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + }; + + /* Touch block @14CE0000 */ + pinctrl@14CE0000 { + gpj1: gpj1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + hs_i2c7_bus: hs-i2c7-bus { + samsung,pins = "gpj1-1", "gpj1-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + }; + + /* FF block @14C90000 */ + pinctrl@14C90000 { + gpg4: gpg4 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + spi3_bus: spi3-bus { + samsung,pins = "gpg4-0", "gpg4-1", "gpg4-2", "gpg4-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + }; + + /* ESE block @14CA0000 */ + pinctrl@14CA0000 { + gpv7: gpv7 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + spi4_bus: spi4-bus { + samsung,pins = "gpv7-0", "gpv7-1", "gpv7-2", "gpv7-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + }; + + /* FSYS0 block @10E60000 */ + pinctrl@10E60000 { + gpr4: gpr4 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + sd2_clk: sd2-clk { + samsung,pins = "gpr4-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd2_cmd: sd2-cmd { + samsung,pins = "gpr4-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd2_cd: sd2-cd { + samsung,pins = "gpr4-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd2_bus1: sd2-bus-width1 { + samsung,pins = "gpr4-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd2_bus4: sd2-bus-width4 { + samsung,pins = "gpr4-4", "gpr4-5", "gpr4-6"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + }; + + /* FSYS1 block @15690000 */ + pinctrl@15690000 { + gpr0: gpr0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpr1: gpr1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpr2: gpr2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpr3: gpr3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + sd0_clk: sd0-clk { + samsung,pins = "gpr0-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd0_cmd: sd0-cmd { + samsung,pins = "gpr0-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd0_rdqs: sd0-rdqs { + samsung,pins = "gpr0-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <1>; + samsung,pin-drv = <3>; + }; + + sd0_qrdy: sd0-qrdy { + samsung,pins = "gpr0-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <1>; + samsung,pin-drv = <3>; + }; + + sd0_bus1: sd0-bus-width1 { + samsung,pins = "gpr1-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd0_bus4: sd0-bus-width4 { + samsung,pins = "gpr1-1", "gpr1-2", "gpr1-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd0_bus8: sd0-bus-width8 { + samsung,pins = "gpr1-4", "gpr1-5", "gpr1-6", "gpr1-7"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd1_clk: sd1-clk { + samsung,pins = "gpr2-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <2>; + }; + + sd1_cmd: sd1-cmd { + samsung,pins = "gpr2-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <2>; + }; + + sd1_ds: sd1-ds { + samsung,pins = "gpr2-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <1>; + samsung,pin-drv = <6>; + }; + + sd1_qrdy: sd1-qrdy { + samsung,pins = "gpr2-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <1>; + samsung,pin-drv = <6>; + }; + + sd1_int: sd1-int { + samsung,pins = "gpr2-4"; + samsung,pin-function = <2>; + samsung,pin-pud = <1>; + samsung,pin-drv = <6>; + }; + + sd1_bus1: sd1-bus-width1 { + samsung,pins = "gpr3-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <2>; + }; + + sd1_bus4: sd1-bus-width4 { + samsung,pins = "gpr3-1", "gpr3-2", "gpr3-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <2>; + }; + + sd1_bus8: sd1-bus-width8 { + samsung,pins = "gpr3-4", "gpr3-5", "gpr3-6", "gpr3-7"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <2>; + }; + }; +}; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 10/14] arm64: dts: add pinctrl support to EXYNOS7 @ 2014-08-27 9:44 ` Naveen Krishna Chatradhi 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Chatradhi @ 2014-08-27 9:44 UTC (permalink / raw) To: linux-arm-kernel Add the required pin configuration support to EXYNOS7 using pinctrl interface. Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Cc: Thomas Abraham <thomas.ab@samsung.com> Cc: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/boot/dts/exynos7-pinctrl.dtsi | 691 ++++++++++++++++++++++++++++++ 1 file changed, 691 insertions(+) create mode 100644 arch/arm64/boot/dts/exynos7-pinctrl.dtsi diff --git a/arch/arm64/boot/dts/exynos7-pinctrl.dtsi b/arch/arm64/boot/dts/exynos7-pinctrl.dtsi new file mode 100644 index 0000000..96e9d99 --- /dev/null +++ b/arch/arm64/boot/dts/exynos7-pinctrl.dtsi @@ -0,0 +1,691 @@ +/* + * Samsung's Exynos7 SoC pin-mux and pin-config device tree source + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Samsung's Exynos7 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. +*/ + +/ { + /* ALIVE block @10580000 */ + pinctrl at 10580000 { + gpa0: gpa0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&gic>; + interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, + <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>; + }; + + gpa1: gpa1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpa2: gpa2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpa3: gpa3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + + /* AUD block @114B0000 */ + pinctrl at 114B0000 { + gpz0: gpz0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpz1: gpz1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + + /* BUS0 block @13470000 */ + pinctrl at 13470000 { + gpb0: gpb0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + 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>; + }; + + 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>; + }; + + gpd4: gpd4 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd5: gpd5 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd6: gpd6 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd7: gpd7 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd8: gpd8 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpg0: gpg0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpg3: gpg3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + /* HSI2C Sensor 0 */ + hs_i2c10_bus: hs-i2c10-bus { + samsung,pins = "gpb0-1", "gpb0-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + /* HSI2C Sensor 1 */ + hs_i2c11_bus: hs-i2c11-bus { + samsung,pins = "gpb0-3", "gpb0-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + hs_i2c2_bus: hs-i2c2-bus { + samsung,pins = "gpd0-3", "gpd0-2"; + samsung,pin-function = <3>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + uart0_data: uart0-data { + samsung,pins = "gpd0-0", "gpd0-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + uart0_fctl: uart0-fctl { + samsung,pins = "gpd0-2", "gpd0-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + uart2_data: uart2-data { + samsung,pins = "gpd1-4", "gpd1-5"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + hs_i2c3_bus: hs-i2c3-bus { + samsung,pins = "gpd1-3", "gpd1-2"; + samsung,pin-function = <3>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + uart1_data: uart1-data { + samsung,pins = "gpd1-0", "gpd1-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + uart1_fctl: uart1-fctl { + samsung,pins = "gpd1-2", "gpd1-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + hs_i2c0_bus: hs-i2c0-bus { + samsung,pins = "gpd2-1", "gpd2-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + hs_i2c1_bus: hs-i2c1-bus { + samsung,pins = "gpd2-3", "gpd2-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + hs_i2c9_bus: hs-i2c9-bus { + samsung,pins = "gpd2-7", "gpd2-6"; + samsung,pin-function = <3>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + hs_i2c8_bus: hs-i2c8-bus { + samsung,pins = "gpd5-3", "gpd5-2"; + samsung,pin-function = <3>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + uart3_data: uart3-data { + samsung,pins = "gpd5-0", "gpd5-1"; + samsung,pin-function = <3>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + disp_teson: disp_teson { + samsung,pins = "gpg0-1"; + samsung,pin-function = <2>; + }; + + disp_tesoff: disp_tesoff { + samsung,pins = "gpg0-1"; + samsung,pin-function = <0>; + }; + + spi2_bus: spi2-bus { + samsung,pins = "gpd5-0", "gpd5-1", "gpd5-2", "gpd5-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + spi1_bus: spi1-bus { + samsung,pins = "gpd6-2", "gpd6-3", "gpd6-4", "gpd6-5"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + spi0_bus: spi0-bus { + samsung,pins = "gpd8-0", "gpd8-1", "gpd6-0", "gpd6-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + /* HSI2C sensor 2 */ + hs_i2c4_bus: hs-i2c4-bus { + samsung,pins = "gpg3-1", "gpg3-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + /* HSI2C sensor 3 */ + hs_i2c5_bus: hs-i2c5-bus { + samsung,pins = "gpg3-3", "gpg3-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + }; + + /* BUS1 block @14870000 */ + pinctrl at 14870000 { + etc1: etc1 { + 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>; + }; + + gpf2: gpf2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpf3: gpf3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpf4: gpf4 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpf5: gpf5 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpg1: gpg1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpg2: gpg2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gph1: gph1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpv6: gpv6 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + + /* NFC block @14CD0000 */ + pinctrl at 14CD0000 { + gpj0: gpj0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + hs_i2c6_bus: hs-i2c6-bus { + samsung,pins = "gpj0-1", "gpj0-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + }; + + /* Touch block @14CE0000 */ + pinctrl at 14CE0000 { + gpj1: gpj1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + hs_i2c7_bus: hs-i2c7-bus { + samsung,pins = "gpj1-1", "gpj1-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + }; + + /* FF block @14C90000 */ + pinctrl at 14C90000 { + gpg4: gpg4 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + spi3_bus: spi3-bus { + samsung,pins = "gpg4-0", "gpg4-1", "gpg4-2", "gpg4-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + }; + + /* ESE block @14CA0000 */ + pinctrl at 14CA0000 { + gpv7: gpv7 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + spi4_bus: spi4-bus { + samsung,pins = "gpv7-0", "gpv7-1", "gpv7-2", "gpv7-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + }; + + /* FSYS0 block @10E60000 */ + pinctrl at 10E60000 { + gpr4: gpr4 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + sd2_clk: sd2-clk { + samsung,pins = "gpr4-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd2_cmd: sd2-cmd { + samsung,pins = "gpr4-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd2_cd: sd2-cd { + samsung,pins = "gpr4-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd2_bus1: sd2-bus-width1 { + samsung,pins = "gpr4-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd2_bus4: sd2-bus-width4 { + samsung,pins = "gpr4-4", "gpr4-5", "gpr4-6"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + }; + + /* FSYS1 block @15690000 */ + pinctrl at 15690000 { + gpr0: gpr0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpr1: gpr1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpr2: gpr2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpr3: gpr3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + sd0_clk: sd0-clk { + samsung,pins = "gpr0-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd0_cmd: sd0-cmd { + samsung,pins = "gpr0-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd0_rdqs: sd0-rdqs { + samsung,pins = "gpr0-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <1>; + samsung,pin-drv = <3>; + }; + + sd0_qrdy: sd0-qrdy { + samsung,pins = "gpr0-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <1>; + samsung,pin-drv = <3>; + }; + + sd0_bus1: sd0-bus-width1 { + samsung,pins = "gpr1-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd0_bus4: sd0-bus-width4 { + samsung,pins = "gpr1-1", "gpr1-2", "gpr1-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd0_bus8: sd0-bus-width8 { + samsung,pins = "gpr1-4", "gpr1-5", "gpr1-6", "gpr1-7"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd1_clk: sd1-clk { + samsung,pins = "gpr2-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <2>; + }; + + sd1_cmd: sd1-cmd { + samsung,pins = "gpr2-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <2>; + }; + + sd1_ds: sd1-ds { + samsung,pins = "gpr2-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <1>; + samsung,pin-drv = <6>; + }; + + sd1_qrdy: sd1-qrdy { + samsung,pins = "gpr2-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <1>; + samsung,pin-drv = <6>; + }; + + sd1_int: sd1-int { + samsung,pins = "gpr2-4"; + samsung,pin-function = <2>; + samsung,pin-pud = <1>; + samsung,pin-drv = <6>; + }; + + sd1_bus1: sd1-bus-width1 { + samsung,pins = "gpr3-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <2>; + }; + + sd1_bus4: sd1-bus-width4 { + samsung,pins = "gpr3-1", "gpr3-2", "gpr3-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <2>; + }; + + sd1_bus8: sd1-bus-width8 { + samsung,pins = "gpr3-4", "gpr3-5", "gpr3-6", "gpr3-7"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <2>; + }; + }; +}; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: [PATCH 10/14] arm64: dts: add pinctrl support to EXYNOS7 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-27 11:14 ` Tomasz Figa -1 siblings, 0 replies; 84+ messages in thread From: Tomasz Figa @ 2014-08-27 11:14 UTC (permalink / raw) To: Naveen Krishna Chatradhi, catalin.marinas Cc: naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Hi Naveen, Please see my comments inline. On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: > Add the required pin configuration support to EXYNOS7 [snip] > +/ { > + /* ALIVE block @10580000 */ > + pinctrl@10580000 { This syntax repeating the whole hierarchy of nodes in every dts file is considered obsolete in case of Exynos DT sources. Please switch to reference-based one. Please see related files for Exynos5260 and 5800 as examples. [snip] > + disp_teson: disp_teson { > + samsung,pins = "gpg0-1"; > + samsung,pin-function = <2>; > + }; > + > + disp_tesoff: disp_tesoff { > + samsung,pins = "gpg0-1"; > + samsung,pin-function = <0>; This is not a special function, so I don't think it belongs to this file. Best regards, Tomasz ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 10/14] arm64: dts: add pinctrl support to EXYNOS7 @ 2014-08-27 11:14 ` Tomasz Figa 0 siblings, 0 replies; 84+ messages in thread From: Tomasz Figa @ 2014-08-27 11:14 UTC (permalink / raw) To: linux-arm-kernel Hi Naveen, Please see my comments inline. On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: > Add the required pin configuration support to EXYNOS7 [snip] > +/ { > + /* ALIVE block @10580000 */ > + pinctrl at 10580000 { This syntax repeating the whole hierarchy of nodes in every dts file is considered obsolete in case of Exynos DT sources. Please switch to reference-based one. Please see related files for Exynos5260 and 5800 as examples. [snip] > + disp_teson: disp_teson { > + samsung,pins = "gpg0-1"; > + samsung,pin-function = <2>; > + }; > + > + disp_tesoff: disp_tesoff { > + samsung,pins = "gpg0-1"; > + samsung,pin-function = <0>; This is not a special function, so I don't think it belongs to this file. Best regards, Tomasz ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 10/14] arm64: dts: add pinctrl support to EXYNOS7 2014-08-27 11:14 ` Tomasz Figa @ 2014-08-29 5:46 ` Naveen Krishna Ch -1 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-08-29 5:46 UTC (permalink / raw) To: Tomasz Figa Cc: Naveen Krishna Chatradhi, catalin.marinas, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Hello Tomasz, On 27 August 2014 16:44, Tomasz Figa <t.figa@samsung.com> wrote: > Hi Naveen, > > Please see my comments inline. > > On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: >> Add the required pin configuration support to EXYNOS7 > > [snip] > >> +/ { >> + /* ALIVE block @10580000 */ >> + pinctrl@10580000 { > > This syntax repeating the whole hierarchy of nodes in every dts file is > considered obsolete in case of Exynos DT sources. Please switch to > reference-based one. Please see related files for Exynos5260 and 5800 as > examples. Sure, will respin with reference based usage. > > [snip] > >> + disp_teson: disp_teson { >> + samsung,pins = "gpg0-1"; >> + samsung,pin-function = <2>; >> + }; >> + >> + disp_tesoff: disp_tesoff { >> + samsung,pins = "gpg0-1"; >> + samsung,pin-function = <0>; > > This is not a special function, so I don't think it belongs to this file. > > Best regards, > Tomasz Thanks for the in depth review. Will fixes the comments. -- Thanks & Regards, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 10/14] arm64: dts: add pinctrl support to EXYNOS7 @ 2014-08-29 5:46 ` Naveen Krishna Ch 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-08-29 5:46 UTC (permalink / raw) To: linux-arm-kernel Hello Tomasz, On 27 August 2014 16:44, Tomasz Figa <t.figa@samsung.com> wrote: > Hi Naveen, > > Please see my comments inline. > > On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: >> Add the required pin configuration support to EXYNOS7 > > [snip] > >> +/ { >> + /* ALIVE block @10580000 */ >> + pinctrl at 10580000 { > > This syntax repeating the whole hierarchy of nodes in every dts file is > considered obsolete in case of Exynos DT sources. Please switch to > reference-based one. Please see related files for Exynos5260 and 5800 as > examples. Sure, will respin with reference based usage. > > [snip] > >> + disp_teson: disp_teson { >> + samsung,pins = "gpg0-1"; >> + samsung,pin-function = <2>; >> + }; >> + >> + disp_tesoff: disp_tesoff { >> + samsung,pins = "gpg0-1"; >> + samsung,pin-function = <0>; > > This is not a special function, so I don't think it belongs to this file. > > Best regards, > Tomasz Thanks for the in depth review. Will fixes the comments. -- Thanks & Regards, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-27 9:44 ` Naveen Krishna Chatradhi -1 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Chatradhi @ 2014-08-27 9:44 UTC (permalink / raw) To: catalin.marinas Cc: naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Add initial device tree nodes for EXYNOS7 SoC. Also, includes the dt-binding definitions for clock ids. Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Cc: Thomas Abraham <thomas.ab@samsung.com> Cc: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 553 insertions(+) create mode 100644 arch/arm64/boot/dts/exynos7.dtsi diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi new file mode 100644 index 0000000..6b9eaf4 --- /dev/null +++ b/arch/arm64/boot/dts/exynos7.dtsi @@ -0,0 +1,553 @@ +/* + * SAMSUNG EXYNOS7 SoC device tree source + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. + * EXYNOS7 based board files can include this file and provide + * values for board specfic bindings. + * + * 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 <dt-bindings/clock/exynos7-clk.h> + +/ { + compatible = "samsung,exynos7"; + interrupt-parent = <&gic>; + #address-cells = <1>; + #size-cells = <1>; + + aliases { + pinctrl0 = &pinctrl_0; + pinctrl1 = &pinctrl_1; + pinctrl2 = &pinctrl_2; + pinctrl3 = &pinctrl_3; + pinctrl4 = &pinctrl_4; + pinctrl5 = &pinctrl_5; + pinctrl6 = &pinctrl_6; + pinctrl7 = &pinctrl_7; + pinctrl8 = &pinctrl_8; + pinctrl9 = &pinctrl_9; + mshc0 = &mmc_0; + mshc2 = &mmc_2; + }; + + chipid@10000000 { + compatible = "samsung,exynos4210-chipid"; + reg = <0x10000000 0x100>; + }; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a57", "arm,armv8"; + reg = <0x0 0x0>; + }; + }; + + fin_pll: xxti { + compatible = "fixed-clock"; + clock-frequency = <24000000>; + clock-output-names = "fin_pll"; + #clock-cells = <0>; + }; + + gic: interrupt-controller@11001000 { + compatible = "arm,gic-400"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x11001000 0x1000>, + <0x11002000 0x1000>, + <0x11004000 0x2000>, + <0x11006000 0x2000>; + }; + + hsi2c_0: hsi2c@13640000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13640000 0x1000>; + interrupts = <0 441 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c0_bus>; + clocks = <&clock_peric0 PCLK_HSI2C0>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_1: hsi2c@13650000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13650000 0x1000>; + interrupts = <0 442 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c1_bus>; + clocks = <&clock_peric0 PCLK_HSI2C1>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_2: hsi2c@14E60000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x14E60000 0x1000>; + interrupts = <0 459 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c2_bus>; + clocks = <&clock_peric1 PCLK_HSI2C2>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_3: hsi2c@14E70000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x14E70000 0x1000>; + interrupts = <0 460 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c3_bus>; + clocks = <&clock_peric1 PCLK_HSI2C3>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_4: hsi2c@13660000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13660000 0x1000>; + interrupts = <0 443 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c4_bus>; + clocks = <&clock_peric0 PCLK_HSI2C4>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_5: hsi2c@13670000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13670000 0x1000>; + interrupts = <0 444 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c5_bus>; + clocks = <&clock_peric0 PCLK_HSI2C5>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_6: hsi2c@14E00000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x14E00000 0x1000>; + interrupts = <0 461 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c6_bus>; + clocks = <&clock_peric1 PCLK_HSI2C6>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_7: hsi2c@13E10000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13E10000 0x1000>; + interrupts = <0 462 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c7_bus>; + clocks = <&clock_peric1 PCLK_HSI2C7>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_8: hsi2c@14E20000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x14E20000 0x1000>; + interrupts = <0 463 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c8_bus>; + clocks = <&clock_peric1 PCLK_HSI2C8>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_9: hsi2c@13680000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13680000 0x1000>; + interrupts = <0 445 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c9_bus>; + clocks = <&clock_peric0 PCLK_HSI2C9>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_10: hsi2c@13690000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13690000 0x1000>; + interrupts = <0 446 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c10_bus>; + clocks = <&clock_peric0 PCLK_HSI2C10>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_11: hsi2c@136A0000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x136A0000 0x1000>; + interrupts = <0 447 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c11_bus>; + clocks = <&clock_peric0 PCLK_HSI2C11>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + mct@101C0000 { + compatible = "samsung,exynos4210-mct"; + reg = <0x101C0000 0x800>; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&mct_map>; + interrupts = <0>, <1>, <2>, <3>, + <4>, <5>, <6>, <7>, + <8>, <9>, <10>, <11>; + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>; + clock-names = "fin_pll", "mct"; + + mct_map: mct-map { + #interrupt-cells = <1>; + #address-cells = <0>; + #size-cells = <0>; + interrupt-map = <0 &gic 0 112 0>, + <1 &gic 0 113 0>, + <2 &gic 0 114 0>, + <3 &gic 0 115 0>, + <4 &gic 0 116 0>, + <5 &gic 0 117 0>, + <6 &gic 0 118 0>, + <7 &gic 0 119 0>, + <8 &gic 0 120 0>, + <9 &gic 0 121 0>, + <10 &gic 0 122 0>, + <11 &gic 0 123 0>; + }; + }; + + mmc_0: mmc@15740000 { + compatible = "samsung,exynos7-dw-mshc-smu"; + interrupts = <0 201 0>; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x15740000 0x2000>; + clocks = <&clock_fsys1 ACLK_MMC0>, + <&clock_top1 CLK_SCLK_MMC0>; + clock-names = "biu", "ciu"; + fifo-depth = <0x40>; + status = "disabled"; + }; + + mmc_2: mmc@15560000 { + compatible = "samsung,exynos7-dw-mshc-smu"; + interrupts = <0 216 0>; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x15560000 0x2000>; + clocks = <&clock_fsys0 ACLK_MMC2>, + <&clock_top1 CLK_SCLK_MMC2>; + clock-names = "biu", "ciu"; + fifo-depth = <0x40>; + status = "disabled"; + }; + + pinctrl_0: pinctrl@10580000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x10580000 0x1000>; + interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, + <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, + <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, + <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>; + wakeup-interrupt-controller { + compatible = "samsung,exynos4210-wakeup-eint"; + interrupt-parent = <&gic>; + interrupts = <0 16 0>; + }; + }; + + pinctrl_1: pinctrl@114B0000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x114B0000 0x1000>; + interrupts = <0 92 0>; + }; + + pinctrl_2: pinctrl@13470000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x13470000 0x1000>; + interrupts = <0 383 0>; + }; + + pinctrl_3: pinctrl@14870000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x14870000 0x1000>; + interrupts = <0 384 0>; + }; + + pinctrl_4: pinctrl@14CD0000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x14CD0000 0x1000>; + interrupts = <0 473 0>; + }; + + pinctrl_5: pinctrl@14CE0000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x14CE0000 0x1000>; + interrupts = <0 474 0>; + }; + + pinctrl_6: pinctrl@14C90000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x14C90000 0x1000>; + interrupts = <0 475 0>; + }; + + pinctrl_7: pinctrl@14CA0000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x14CA0000 0x1000>; + interrupts = <0 476 0>; + }; + + pinctrl_8: pinctrl@10E60000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x10E60000 0x1000>; + interrupts = <0 221 0>; + }; + + pinctrl_9: pinctrl@15690000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x15690000 0x1000>; + interrupts = <0 203 0>; + }; + + pwm: pwm@136C0000 { + compatible = "samsung,exynos4210-pwm"; + reg = <0x136C0000 0x100>; + samsung,pwm-outputs = <0>, <1>, <2>, <3>; + #pwm-cells = <3>; + clocks = <&clock_peric0 PCLK_PWM>; + clock-names = "timers"; + status = "disabled"; + }; + + rtc@10590000 { + compatible = "samsung,s3c6410-rtc"; + reg = <0x10590000 0x100>; + interrupts = <0 355 0>, <0 356 0>; + clocks = <&clock_ccore PCLK_RTC>; + clock-names = "rtc"; + }; + + serial@13630000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x13630000 0x100>; + interrupts = <0 440 0>; + clocks = <&clock_peric0 PCLK_UART0>, <&clock_peric0 SCLK_UART0>; + clock-names = "uart", "clk_uart_baud0"; + status = "okay"; + }; + + serial@14C20000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x14C20000 0x100>; + interrupts = <0 456 0>; + clocks = <&clock_peric1 PCLK_UART1>, <&clock_peric1 SCLK_UART1>; + clock-names = "uart", "clk_uart_baud1"; + status = "okay"; + }; + + serial@14C30000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x14C30000 0x100>; + interrupts = <0 457 0>; + clocks = <&clock_peric1 PCLK_UART2>, <&clock_peric1 SCLK_UART2>; + clock-names = "uart", "clk_uart_baud2"; + status = "okay"; + }; + + serial@14C40000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x14C40000 0x100>; + interrupts = <0 458 0>; + clocks = <&clock_peric1 PCLK_UART3>, <&clock_peric1 SCLK_UART3>; + clock-names = "uart", "clk_uart_baud3"; + status = "okay"; + }; + + /* The Clock nodes are ordered as per the usermanual. */ + clock_topc: clock-controller@10570000 { + compatible = "samsung,exynos7-clock-topc"; + reg = <0x10570000 0x10000>; + #clock-cells = <1>; + }; + + clock_top0: clock-controller@105D0000 { + compatible = "samsung,exynos7-clock-top0"; + reg = <0x105D0000 0xB000>; + #clock-cells = <1>; + }; + + clock_top1: clock-controller@105E0000 { + compatible = "samsung,exynos7-clock-top1"; + reg = <0x105E0000 0xB000>; + #clock-cells = <1>; + }; + + clock_atlas: clock-controller@11800000 { + compatible = "samsung,exynos7-clock-atlas"; + reg = <0x11800000 0x1100>; + #clock-cells = <1>; + }; + + clock_g3d: clock-controller@14AA0000 { + compatible = "samsung,exynos7-clock-g3d"; + reg = <0x14AA0000 0x1100>; + #clock-cells = <1>; + }; + + clock_mif0: clock-controller@10850000 { + compatible = "samsung,exynos7-clock-mif0"; + reg = <0x10850000 0x1100>; + #clock-cells = <1>; + }; + + clock_mif1: clock-controller@10950000 { + compatible = "samsung,exynos7-clock-mif1"; + reg = <0x10950000 0x1100>; + #clock-cells = <1>; + }; + + clock_mif2: clock-controller@10A50000 { + compatible = "samsung,exynos7-clock-mif2"; + reg = <0x10A50000 0x1100>; + #clock-cells = <1>; + }; + + clock_mif3: clock-controller@10B50000 { + compatible = "samsung,exynos7-clock-mif3"; + reg = <0x10B50000 0x1100>; + #clock-cells = <1>; + }; + + clock_ccore: clock-controller@105B0000 { + compatible = "samsung,exynos7-clock-ccore"; + reg = <0x105B0000 0xD00>; + #clock-cells = <1>; + }; + + clock_imem: clock-controller@11060000 { + compatible = "samsung,exynos7-clock-imem"; + reg = <0x11060000 0xD00>; + #clock-cells = <1>; + }; + + clock_peric0: clock-controller@13610000 { + compatible = "samsung,exynos7-clock-peric0"; + reg = <0x13610000 0xD00>; + #clock-cells = <1>; + }; + + clock_peric1: clock-controller@14C80000 { + compatible = "samsung,exynos7-clock-peric1"; + reg = <0x14C80000 0xD00>; + #clock-cells = <1>; + }; + + clock_peris: clock-controller@10040000 { + compatible = "samsung,exynos7-clock-peris"; + reg = <0x10040000 0xD00>; + #clock-cells = <1>; + }; + + clock_bus0: clock-controller@13400000 { + compatible = "samsung,exynos7-clock-bus0"; + reg = <0x13400000 0xD00>; + #clock-cells = <1>; + }; + + clock_bus1: clock-controller@14800000 { + compatible = "samsung,exynos7-clock-bus1"; + reg = <0x14800000 0xD00>; + #clock-cells = <1>; + }; + + clock_disp: clock-controller@13AD0000 { + compatible = "samsung,exynos7-clock-disp"; + reg = <0x13AD0000 0xD00>; + #clock-cells = <1>; + }; + + clock_aud: clock-controller@114C0000 { + compatible = "samsung,exynos7-clock-aud"; + reg = <0x114C0000 0xD00>; + #clock-cells = <1>; + }; + + clock_fsys0: clock-controller@10E90000 { + compatible = "samsung,exynos7-clock-fsys0"; + reg = <0x10E90000 0xD00>; + #clock-cells = <1>; + }; + + clock_fsys1: clock-controller@156E0000 { + compatible = "samsung,exynos7-clock-fsys1"; + reg = <0x156E0000 0xD00>; + #clock-cells = <1>; + }; + + clock_mscl: clock-controller@150D0000 { + compatible = "samsung,exynos7-clock-mscl"; + reg = <0x150D0000 0xD00>; + #clock-cells = <1>; + }; + + clock_mfc: clock-controller@15280000 { + compatible = "samsung,exynos7-clock-mfc"; + reg = <0x15280000 0xD00>; + #clock-cells = <1>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0xff01>, + <1 14 0xff01>, + <1 11 0xff01>, + <1 10 0xff01>; + clock-frequency = <24000000>; + use-clocksource-only; + use-physical-timer; + }; +}; + +#include "exynos7-pinctrl.dtsi" -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-27 9:44 ` Naveen Krishna Chatradhi 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Chatradhi @ 2014-08-27 9:44 UTC (permalink / raw) To: linux-arm-kernel Add initial device tree nodes for EXYNOS7 SoC. Also, includes the dt-binding definitions for clock ids. Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Cc: Thomas Abraham <thomas.ab@samsung.com> Cc: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 553 insertions(+) create mode 100644 arch/arm64/boot/dts/exynos7.dtsi diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi new file mode 100644 index 0000000..6b9eaf4 --- /dev/null +++ b/arch/arm64/boot/dts/exynos7.dtsi @@ -0,0 +1,553 @@ +/* + * SAMSUNG EXYNOS7 SoC device tree source + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. + * EXYNOS7 based board files can include this file and provide + * values for board specfic bindings. + * + * 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 <dt-bindings/clock/exynos7-clk.h> + +/ { + compatible = "samsung,exynos7"; + interrupt-parent = <&gic>; + #address-cells = <1>; + #size-cells = <1>; + + aliases { + pinctrl0 = &pinctrl_0; + pinctrl1 = &pinctrl_1; + pinctrl2 = &pinctrl_2; + pinctrl3 = &pinctrl_3; + pinctrl4 = &pinctrl_4; + pinctrl5 = &pinctrl_5; + pinctrl6 = &pinctrl_6; + pinctrl7 = &pinctrl_7; + pinctrl8 = &pinctrl_8; + pinctrl9 = &pinctrl_9; + mshc0 = &mmc_0; + mshc2 = &mmc_2; + }; + + chipid at 10000000 { + compatible = "samsung,exynos4210-chipid"; + reg = <0x10000000 0x100>; + }; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + cpu at 0 { + device_type = "cpu"; + compatible = "arm,cortex-a57", "arm,armv8"; + reg = <0x0 0x0>; + }; + }; + + fin_pll: xxti { + compatible = "fixed-clock"; + clock-frequency = <24000000>; + clock-output-names = "fin_pll"; + #clock-cells = <0>; + }; + + gic: interrupt-controller at 11001000 { + compatible = "arm,gic-400"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x11001000 0x1000>, + <0x11002000 0x1000>, + <0x11004000 0x2000>, + <0x11006000 0x2000>; + }; + + hsi2c_0: hsi2c at 13640000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13640000 0x1000>; + interrupts = <0 441 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c0_bus>; + clocks = <&clock_peric0 PCLK_HSI2C0>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_1: hsi2c at 13650000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13650000 0x1000>; + interrupts = <0 442 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c1_bus>; + clocks = <&clock_peric0 PCLK_HSI2C1>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_2: hsi2c at 14E60000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x14E60000 0x1000>; + interrupts = <0 459 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c2_bus>; + clocks = <&clock_peric1 PCLK_HSI2C2>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_3: hsi2c at 14E70000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x14E70000 0x1000>; + interrupts = <0 460 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c3_bus>; + clocks = <&clock_peric1 PCLK_HSI2C3>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_4: hsi2c at 13660000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13660000 0x1000>; + interrupts = <0 443 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c4_bus>; + clocks = <&clock_peric0 PCLK_HSI2C4>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_5: hsi2c at 13670000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13670000 0x1000>; + interrupts = <0 444 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c5_bus>; + clocks = <&clock_peric0 PCLK_HSI2C5>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_6: hsi2c at 14E00000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x14E00000 0x1000>; + interrupts = <0 461 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c6_bus>; + clocks = <&clock_peric1 PCLK_HSI2C6>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_7: hsi2c at 13E10000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13E10000 0x1000>; + interrupts = <0 462 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c7_bus>; + clocks = <&clock_peric1 PCLK_HSI2C7>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_8: hsi2c at 14E20000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x14E20000 0x1000>; + interrupts = <0 463 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c8_bus>; + clocks = <&clock_peric1 PCLK_HSI2C8>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_9: hsi2c at 13680000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13680000 0x1000>; + interrupts = <0 445 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c9_bus>; + clocks = <&clock_peric0 PCLK_HSI2C9>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_10: hsi2c at 13690000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x13690000 0x1000>; + interrupts = <0 446 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c10_bus>; + clocks = <&clock_peric0 PCLK_HSI2C10>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + hsi2c_11: hsi2c at 136A0000 { + compatible = "samsung,exynos7-hsi2c"; + reg = <0x136A0000 0x1000>; + interrupts = <0 447 0>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&hs_i2c11_bus>; + clocks = <&clock_peric0 PCLK_HSI2C11>; + clock-names = "hsi2c"; + status = "disabled"; + }; + + mct at 101C0000 { + compatible = "samsung,exynos4210-mct"; + reg = <0x101C0000 0x800>; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&mct_map>; + interrupts = <0>, <1>, <2>, <3>, + <4>, <5>, <6>, <7>, + <8>, <9>, <10>, <11>; + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>; + clock-names = "fin_pll", "mct"; + + mct_map: mct-map { + #interrupt-cells = <1>; + #address-cells = <0>; + #size-cells = <0>; + interrupt-map = <0 &gic 0 112 0>, + <1 &gic 0 113 0>, + <2 &gic 0 114 0>, + <3 &gic 0 115 0>, + <4 &gic 0 116 0>, + <5 &gic 0 117 0>, + <6 &gic 0 118 0>, + <7 &gic 0 119 0>, + <8 &gic 0 120 0>, + <9 &gic 0 121 0>, + <10 &gic 0 122 0>, + <11 &gic 0 123 0>; + }; + }; + + mmc_0: mmc at 15740000 { + compatible = "samsung,exynos7-dw-mshc-smu"; + interrupts = <0 201 0>; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x15740000 0x2000>; + clocks = <&clock_fsys1 ACLK_MMC0>, + <&clock_top1 CLK_SCLK_MMC0>; + clock-names = "biu", "ciu"; + fifo-depth = <0x40>; + status = "disabled"; + }; + + mmc_2: mmc at 15560000 { + compatible = "samsung,exynos7-dw-mshc-smu"; + interrupts = <0 216 0>; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x15560000 0x2000>; + clocks = <&clock_fsys0 ACLK_MMC2>, + <&clock_top1 CLK_SCLK_MMC2>; + clock-names = "biu", "ciu"; + fifo-depth = <0x40>; + status = "disabled"; + }; + + pinctrl_0: pinctrl at 10580000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x10580000 0x1000>; + interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, + <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, + <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, + <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>; + wakeup-interrupt-controller { + compatible = "samsung,exynos4210-wakeup-eint"; + interrupt-parent = <&gic>; + interrupts = <0 16 0>; + }; + }; + + pinctrl_1: pinctrl at 114B0000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x114B0000 0x1000>; + interrupts = <0 92 0>; + }; + + pinctrl_2: pinctrl at 13470000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x13470000 0x1000>; + interrupts = <0 383 0>; + }; + + pinctrl_3: pinctrl at 14870000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x14870000 0x1000>; + interrupts = <0 384 0>; + }; + + pinctrl_4: pinctrl at 14CD0000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x14CD0000 0x1000>; + interrupts = <0 473 0>; + }; + + pinctrl_5: pinctrl at 14CE0000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x14CE0000 0x1000>; + interrupts = <0 474 0>; + }; + + pinctrl_6: pinctrl at 14C90000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x14C90000 0x1000>; + interrupts = <0 475 0>; + }; + + pinctrl_7: pinctrl at 14CA0000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x14CA0000 0x1000>; + interrupts = <0 476 0>; + }; + + pinctrl_8: pinctrl at 10E60000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x10E60000 0x1000>; + interrupts = <0 221 0>; + }; + + pinctrl_9: pinctrl at 15690000 { + compatible = "samsung,exynos7-pinctrl"; + reg = <0x15690000 0x1000>; + interrupts = <0 203 0>; + }; + + pwm: pwm at 136C0000 { + compatible = "samsung,exynos4210-pwm"; + reg = <0x136C0000 0x100>; + samsung,pwm-outputs = <0>, <1>, <2>, <3>; + #pwm-cells = <3>; + clocks = <&clock_peric0 PCLK_PWM>; + clock-names = "timers"; + status = "disabled"; + }; + + rtc at 10590000 { + compatible = "samsung,s3c6410-rtc"; + reg = <0x10590000 0x100>; + interrupts = <0 355 0>, <0 356 0>; + clocks = <&clock_ccore PCLK_RTC>; + clock-names = "rtc"; + }; + + serial at 13630000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x13630000 0x100>; + interrupts = <0 440 0>; + clocks = <&clock_peric0 PCLK_UART0>, <&clock_peric0 SCLK_UART0>; + clock-names = "uart", "clk_uart_baud0"; + status = "okay"; + }; + + serial at 14C20000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x14C20000 0x100>; + interrupts = <0 456 0>; + clocks = <&clock_peric1 PCLK_UART1>, <&clock_peric1 SCLK_UART1>; + clock-names = "uart", "clk_uart_baud1"; + status = "okay"; + }; + + serial at 14C30000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x14C30000 0x100>; + interrupts = <0 457 0>; + clocks = <&clock_peric1 PCLK_UART2>, <&clock_peric1 SCLK_UART2>; + clock-names = "uart", "clk_uart_baud2"; + status = "okay"; + }; + + serial at 14C40000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x14C40000 0x100>; + interrupts = <0 458 0>; + clocks = <&clock_peric1 PCLK_UART3>, <&clock_peric1 SCLK_UART3>; + clock-names = "uart", "clk_uart_baud3"; + status = "okay"; + }; + + /* The Clock nodes are ordered as per the usermanual. */ + clock_topc: clock-controller at 10570000 { + compatible = "samsung,exynos7-clock-topc"; + reg = <0x10570000 0x10000>; + #clock-cells = <1>; + }; + + clock_top0: clock-controller at 105D0000 { + compatible = "samsung,exynos7-clock-top0"; + reg = <0x105D0000 0xB000>; + #clock-cells = <1>; + }; + + clock_top1: clock-controller at 105E0000 { + compatible = "samsung,exynos7-clock-top1"; + reg = <0x105E0000 0xB000>; + #clock-cells = <1>; + }; + + clock_atlas: clock-controller at 11800000 { + compatible = "samsung,exynos7-clock-atlas"; + reg = <0x11800000 0x1100>; + #clock-cells = <1>; + }; + + clock_g3d: clock-controller at 14AA0000 { + compatible = "samsung,exynos7-clock-g3d"; + reg = <0x14AA0000 0x1100>; + #clock-cells = <1>; + }; + + clock_mif0: clock-controller at 10850000 { + compatible = "samsung,exynos7-clock-mif0"; + reg = <0x10850000 0x1100>; + #clock-cells = <1>; + }; + + clock_mif1: clock-controller at 10950000 { + compatible = "samsung,exynos7-clock-mif1"; + reg = <0x10950000 0x1100>; + #clock-cells = <1>; + }; + + clock_mif2: clock-controller at 10A50000 { + compatible = "samsung,exynos7-clock-mif2"; + reg = <0x10A50000 0x1100>; + #clock-cells = <1>; + }; + + clock_mif3: clock-controller at 10B50000 { + compatible = "samsung,exynos7-clock-mif3"; + reg = <0x10B50000 0x1100>; + #clock-cells = <1>; + }; + + clock_ccore: clock-controller at 105B0000 { + compatible = "samsung,exynos7-clock-ccore"; + reg = <0x105B0000 0xD00>; + #clock-cells = <1>; + }; + + clock_imem: clock-controller at 11060000 { + compatible = "samsung,exynos7-clock-imem"; + reg = <0x11060000 0xD00>; + #clock-cells = <1>; + }; + + clock_peric0: clock-controller at 13610000 { + compatible = "samsung,exynos7-clock-peric0"; + reg = <0x13610000 0xD00>; + #clock-cells = <1>; + }; + + clock_peric1: clock-controller at 14C80000 { + compatible = "samsung,exynos7-clock-peric1"; + reg = <0x14C80000 0xD00>; + #clock-cells = <1>; + }; + + clock_peris: clock-controller at 10040000 { + compatible = "samsung,exynos7-clock-peris"; + reg = <0x10040000 0xD00>; + #clock-cells = <1>; + }; + + clock_bus0: clock-controller at 13400000 { + compatible = "samsung,exynos7-clock-bus0"; + reg = <0x13400000 0xD00>; + #clock-cells = <1>; + }; + + clock_bus1: clock-controller at 14800000 { + compatible = "samsung,exynos7-clock-bus1"; + reg = <0x14800000 0xD00>; + #clock-cells = <1>; + }; + + clock_disp: clock-controller at 13AD0000 { + compatible = "samsung,exynos7-clock-disp"; + reg = <0x13AD0000 0xD00>; + #clock-cells = <1>; + }; + + clock_aud: clock-controller at 114C0000 { + compatible = "samsung,exynos7-clock-aud"; + reg = <0x114C0000 0xD00>; + #clock-cells = <1>; + }; + + clock_fsys0: clock-controller at 10E90000 { + compatible = "samsung,exynos7-clock-fsys0"; + reg = <0x10E90000 0xD00>; + #clock-cells = <1>; + }; + + clock_fsys1: clock-controller at 156E0000 { + compatible = "samsung,exynos7-clock-fsys1"; + reg = <0x156E0000 0xD00>; + #clock-cells = <1>; + }; + + clock_mscl: clock-controller at 150D0000 { + compatible = "samsung,exynos7-clock-mscl"; + reg = <0x150D0000 0xD00>; + #clock-cells = <1>; + }; + + clock_mfc: clock-controller at 15280000 { + compatible = "samsung,exynos7-clock-mfc"; + reg = <0x15280000 0xD00>; + #clock-cells = <1>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0xff01>, + <1 14 0xff01>, + <1 11 0xff01>, + <1 10 0xff01>; + clock-frequency = <24000000>; + use-clocksource-only; + use-physical-timer; + }; +}; + +#include "exynos7-pinctrl.dtsi" -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-27 10:42 ` Mark Rutland -1 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-27 10:42 UTC (permalink / raw) To: Naveen Krishna Chatradhi Cc: Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Hi Naveen, On Wed, Aug 27, 2014 at 10:44:18AM +0100, Naveen Krishna Chatradhi wrote: > Add initial device tree nodes for EXYNOS7 SoC. > Also, includes the dt-binding definitions for clock ids. Fallout from a rebase? That latter part doesn't seem to be relevant. > Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> > Cc: Thomas Abraham <thomas.ab@samsung.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 553 insertions(+) > create mode 100644 arch/arm64/boot/dts/exynos7.dtsi > > diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi > new file mode 100644 > index 0000000..6b9eaf4 > --- /dev/null > +++ b/arch/arm64/boot/dts/exynos7.dtsi > @@ -0,0 +1,553 @@ > +/* > + * SAMSUNG EXYNOS7 SoC device tree source > + * > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. > + * EXYNOS7 based board files can include this file and provide > + * values for board specfic bindings. > + * > + * 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 <dt-bindings/clock/exynos7-clk.h> > + > +/ { > + compatible = "samsung,exynos7"; > + interrupt-parent = <&gic>; > + #address-cells = <1>; > + #size-cells = <1>; Can we guarantee everything going to live within 0x0 - 0xffffffff for all boards using the SoC? I suspect that we can't, so the addresses and sizes at the top level should be two cells. At some point there is bound to be something above 4GB that we'll need to map, so to save us from a painful dts refactoring we should have the dts organised to support that from the outside. [...] > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57", "arm,armv8"; > + reg = <0x0 0x0>; > + }; > + }; Only UP? [...] > + gic: interrupt-controller@11001000 { > + compatible = "arm,gic-400"; > + #interrupt-cells = <3>; > + #address-cells = <0>; > + interrupt-controller; > + reg = <0x11001000 0x1000>, > + <0x11002000 0x1000>, > + <0x11004000 0x2000>, > + <0x11006000 0x2000>; > + }; Nice to see GICV and GICH. [...] > + mct@101C0000 { > + compatible = "samsung,exynos4210-mct"; > + reg = <0x101C0000 0x800>; > + interrupt-controller; > + #interrupt-cells = <1>; > + interrupt-parent = <&mct_map>; > + interrupts = <0>, <1>, <2>, <3>, > + <4>, <5>, <6>, <7>, > + <8>, <9>, <10>, <11>; > + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>; > + clock-names = "fin_pll", "mct"; > + > + mct_map: mct-map { > + #interrupt-cells = <1>; > + #address-cells = <0>; > + #size-cells = <0>; > + interrupt-map = <0 &gic 0 112 0>, > + <1 &gic 0 113 0>, > + <2 &gic 0 114 0>, > + <3 &gic 0 115 0>, > + <4 &gic 0 116 0>, > + <5 &gic 0 117 0>, > + <6 &gic 0 118 0>, > + <7 &gic 0 119 0>, > + <8 &gic 0 120 0>, > + <9 &gic 0 121 0>, > + <10 &gic 0 122 0>, > + <11 &gic 0 123 0>; > + }; > + }; I don't see why need the map here. Why can't we describe the GIC interrupts directly? [...] > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <1 13 0xff01>, > + <1 14 0xff01>, > + <1 11 0xff01>, > + <1 10 0xff01>; > + clock-frequency = <24000000>; Your firmware/bootloader should configure CNTFRQ, and this shouldn't be necessary. The clock-frequency property is an incomplete workaround for broken firmware that in an ideal world we could kill off. > + use-clocksource-only; > + use-physical-timer; Neither of these properties were introduced by this series, and no rationale was given. What are these properties for, and why do you believe they are necessary? Thanks, Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-27 10:42 ` Mark Rutland 0 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-27 10:42 UTC (permalink / raw) To: linux-arm-kernel Hi Naveen, On Wed, Aug 27, 2014 at 10:44:18AM +0100, Naveen Krishna Chatradhi wrote: > Add initial device tree nodes for EXYNOS7 SoC. > Also, includes the dt-binding definitions for clock ids. Fallout from a rebase? That latter part doesn't seem to be relevant. > Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> > Cc: Thomas Abraham <thomas.ab@samsung.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 553 insertions(+) > create mode 100644 arch/arm64/boot/dts/exynos7.dtsi > > diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi > new file mode 100644 > index 0000000..6b9eaf4 > --- /dev/null > +++ b/arch/arm64/boot/dts/exynos7.dtsi > @@ -0,0 +1,553 @@ > +/* > + * SAMSUNG EXYNOS7 SoC device tree source > + * > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. > + * EXYNOS7 based board files can include this file and provide > + * values for board specfic bindings. > + * > + * 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 <dt-bindings/clock/exynos7-clk.h> > + > +/ { > + compatible = "samsung,exynos7"; > + interrupt-parent = <&gic>; > + #address-cells = <1>; > + #size-cells = <1>; Can we guarantee everything going to live within 0x0 - 0xffffffff for all boards using the SoC? I suspect that we can't, so the addresses and sizes at the top level should be two cells. At some point there is bound to be something above 4GB that we'll need to map, so to save us from a painful dts refactoring we should have the dts organised to support that from the outside. [...] > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + cpu at 0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57", "arm,armv8"; > + reg = <0x0 0x0>; > + }; > + }; Only UP? [...] > + gic: interrupt-controller at 11001000 { > + compatible = "arm,gic-400"; > + #interrupt-cells = <3>; > + #address-cells = <0>; > + interrupt-controller; > + reg = <0x11001000 0x1000>, > + <0x11002000 0x1000>, > + <0x11004000 0x2000>, > + <0x11006000 0x2000>; > + }; Nice to see GICV and GICH. [...] > + mct at 101C0000 { > + compatible = "samsung,exynos4210-mct"; > + reg = <0x101C0000 0x800>; > + interrupt-controller; > + #interrupt-cells = <1>; > + interrupt-parent = <&mct_map>; > + interrupts = <0>, <1>, <2>, <3>, > + <4>, <5>, <6>, <7>, > + <8>, <9>, <10>, <11>; > + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>; > + clock-names = "fin_pll", "mct"; > + > + mct_map: mct-map { > + #interrupt-cells = <1>; > + #address-cells = <0>; > + #size-cells = <0>; > + interrupt-map = <0 &gic 0 112 0>, > + <1 &gic 0 113 0>, > + <2 &gic 0 114 0>, > + <3 &gic 0 115 0>, > + <4 &gic 0 116 0>, > + <5 &gic 0 117 0>, > + <6 &gic 0 118 0>, > + <7 &gic 0 119 0>, > + <8 &gic 0 120 0>, > + <9 &gic 0 121 0>, > + <10 &gic 0 122 0>, > + <11 &gic 0 123 0>; > + }; > + }; I don't see why need the map here. Why can't we describe the GIC interrupts directly? [...] > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <1 13 0xff01>, > + <1 14 0xff01>, > + <1 11 0xff01>, > + <1 10 0xff01>; > + clock-frequency = <24000000>; Your firmware/bootloader should configure CNTFRQ, and this shouldn't be necessary. The clock-frequency property is an incomplete workaround for broken firmware that in an ideal world we could kill off. > + use-clocksource-only; > + use-physical-timer; Neither of these properties were introduced by this series, and no rationale was given. What are these properties for, and why do you believe they are necessary? Thanks, Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-27 10:42 ` Mark Rutland @ 2014-08-27 14:54 ` Catalin Marinas -1 siblings, 0 replies; 84+ messages in thread From: Catalin Marinas @ 2014-08-27 14:54 UTC (permalink / raw) To: Mark Rutland Cc: Naveen Krishna Chatradhi, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring On Wed, Aug 27, 2014 at 11:42:31AM +0100, Mark Rutland wrote: > On Wed, Aug 27, 2014 at 10:44:18AM +0100, Naveen Krishna Chatradhi wrote: > > + cpus { > > + #address-cells = <2>; > > + #size-cells = <0>; > > + > > + cpu@0 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57", "arm,armv8"; > > + reg = <0x0 0x0>; > > + }; > > + }; > > Only UP? I see what you meant. Maybe this is populated by firmware and that's only an example. -- Catalin ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-27 14:54 ` Catalin Marinas 0 siblings, 0 replies; 84+ messages in thread From: Catalin Marinas @ 2014-08-27 14:54 UTC (permalink / raw) To: linux-arm-kernel On Wed, Aug 27, 2014 at 11:42:31AM +0100, Mark Rutland wrote: > On Wed, Aug 27, 2014 at 10:44:18AM +0100, Naveen Krishna Chatradhi wrote: > > + cpus { > > + #address-cells = <2>; > > + #size-cells = <0>; > > + > > + cpu at 0 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57", "arm,armv8"; > > + reg = <0x0 0x0>; > > + }; > > + }; > > Only UP? I see what you meant. Maybe this is populated by firmware and that's only an example. -- Catalin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-27 10:42 ` Mark Rutland @ 2014-09-03 7:48 ` Naveen Krishna Ch -1 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-09-03 7:48 UTC (permalink / raw) To: Mark Rutland Cc: Naveen Krishna Chatradhi, Catalin Marinas, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Hi Mark, On 27 August 2014 16:12, Mark Rutland <mark.rutland@arm.com> wrote: > Hi Naveen, > > On Wed, Aug 27, 2014 at 10:44:18AM +0100, Naveen Krishna Chatradhi wrote: >> Add initial device tree nodes for EXYNOS7 SoC. >> Also, includes the dt-binding definitions for clock ids. > > Fallout from a rebase? That latter part doesn't seem to be relevant. Yes, this is fixed now. > >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Thomas Abraham <thomas.ab@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 553 insertions(+) >> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi >> >> diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi >> new file mode 100644 >> index 0000000..6b9eaf4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/exynos7.dtsi >> @@ -0,0 +1,553 @@ >> +/* >> + * SAMSUNG EXYNOS7 SoC device tree source >> + * >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. >> + * EXYNOS7 based board files can include this file and provide >> + * values for board specfic bindings. >> + * >> + * 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 <dt-bindings/clock/exynos7-clk.h> >> + >> +/ { >> + compatible = "samsung,exynos7"; >> + interrupt-parent = <&gic>; >> + #address-cells = <1>; >> + #size-cells = <1>; > > Can we guarantee everything going to live within 0x0 - 0xffffffff for > all boards using the SoC? > > I suspect that we can't, so the addresses and sizes at the top level > should be two cells. At some point there is bound to be something above > 4GB that we'll need to map, so to save us from a painful dts refactoring > we should have the dts organised to support that from the outside. Ok, this is fixed with #address-cells = 2 and #size-cells = 2. > > [...] > >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; >> + >> + cpu@0 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a57", "arm,armv8"; >> + reg = <0x0 0x0>; >> + }; >> + }; > > Only UP? This is a quad core SoC and the rest of the CPU nodes have been added in the second version of this series. > > [...] > >> + gic: interrupt-controller@11001000 { >> + compatible = "arm,gic-400"; >> + #interrupt-cells = <3>; >> + #address-cells = <0>; >> + interrupt-controller; >> + reg = <0x11001000 0x1000>, >> + <0x11002000 0x1000>, >> + <0x11004000 0x2000>, >> + <0x11006000 0x2000>; >> + }; > > Nice to see GICV and GICH. > > [...] > >> + mct@101C0000 { >> + compatible = "samsung,exynos4210-mct"; >> + reg = <0x101C0000 0x800>; >> + interrupt-controller; >> + #interrupt-cells = <1>; >> + interrupt-parent = <&mct_map>; >> + interrupts = <0>, <1>, <2>, <3>, >> + <4>, <5>, <6>, <7>, >> + <8>, <9>, <10>, <11>; >> + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>; >> + clock-names = "fin_pll", "mct"; >> + >> + mct_map: mct-map { >> + #interrupt-cells = <1>; >> + #address-cells = <0>; >> + #size-cells = <0>; >> + interrupt-map = <0 &gic 0 112 0>, >> + <1 &gic 0 113 0>, >> + <2 &gic 0 114 0>, >> + <3 &gic 0 115 0>, >> + <4 &gic 0 116 0>, >> + <5 &gic 0 117 0>, >> + <6 &gic 0 118 0>, >> + <7 &gic 0 119 0>, >> + <8 &gic 0 120 0>, >> + <9 &gic 0 121 0>, >> + <10 &gic 0 122 0>, >> + <11 &gic 0 123 0>; >> + }; >> + }; > > I don't see why need the map here. Why can't we describe the GIC > interrupts directly? Right, it was not required. Also, we will try and use only arch timer and not MCT. > > [...] > >> + timer { >> + compatible = "arm,armv8-timer"; >> + interrupts = <1 13 0xff01>, >> + <1 14 0xff01>, >> + <1 11 0xff01>, >> + <1 10 0xff01>; >> + clock-frequency = <24000000>; > > Your firmware/bootloader should configure CNTFRQ, and this shouldn't be > necessary. The clock-frequency property is an incomplete workaround for > broken firmware that in an ideal world we could kill off. > >> + use-clocksource-only; >> + use-physical-timer; > > Neither of these properties were introduced by this series, and no > rationale was given. > > What are these properties for, and why do you believe they are > necessary? Sorry, that was a mistake. This has been fixed. > > Thanks, > Mark. Thanks. -- Shine bright, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-09-03 7:48 ` Naveen Krishna Ch 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-09-03 7:48 UTC (permalink / raw) To: linux-arm-kernel Hi Mark, On 27 August 2014 16:12, Mark Rutland <mark.rutland@arm.com> wrote: > Hi Naveen, > > On Wed, Aug 27, 2014 at 10:44:18AM +0100, Naveen Krishna Chatradhi wrote: >> Add initial device tree nodes for EXYNOS7 SoC. >> Also, includes the dt-binding definitions for clock ids. > > Fallout from a rebase? That latter part doesn't seem to be relevant. Yes, this is fixed now. > >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Thomas Abraham <thomas.ab@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 553 insertions(+) >> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi >> >> diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi >> new file mode 100644 >> index 0000000..6b9eaf4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/exynos7.dtsi >> @@ -0,0 +1,553 @@ >> +/* >> + * SAMSUNG EXYNOS7 SoC device tree source >> + * >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. >> + * EXYNOS7 based board files can include this file and provide >> + * values for board specfic bindings. >> + * >> + * 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 <dt-bindings/clock/exynos7-clk.h> >> + >> +/ { >> + compatible = "samsung,exynos7"; >> + interrupt-parent = <&gic>; >> + #address-cells = <1>; >> + #size-cells = <1>; > > Can we guarantee everything going to live within 0x0 - 0xffffffff for > all boards using the SoC? > > I suspect that we can't, so the addresses and sizes at the top level > should be two cells. At some point there is bound to be something above > 4GB that we'll need to map, so to save us from a painful dts refactoring > we should have the dts organised to support that from the outside. Ok, this is fixed with #address-cells = 2 and #size-cells = 2. > > [...] > >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; >> + >> + cpu at 0 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a57", "arm,armv8"; >> + reg = <0x0 0x0>; >> + }; >> + }; > > Only UP? This is a quad core SoC and the rest of the CPU nodes have been added in the second version of this series. > > [...] > >> + gic: interrupt-controller at 11001000 { >> + compatible = "arm,gic-400"; >> + #interrupt-cells = <3>; >> + #address-cells = <0>; >> + interrupt-controller; >> + reg = <0x11001000 0x1000>, >> + <0x11002000 0x1000>, >> + <0x11004000 0x2000>, >> + <0x11006000 0x2000>; >> + }; > > Nice to see GICV and GICH. > > [...] > >> + mct at 101C0000 { >> + compatible = "samsung,exynos4210-mct"; >> + reg = <0x101C0000 0x800>; >> + interrupt-controller; >> + #interrupt-cells = <1>; >> + interrupt-parent = <&mct_map>; >> + interrupts = <0>, <1>, <2>, <3>, >> + <4>, <5>, <6>, <7>, >> + <8>, <9>, <10>, <11>; >> + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>; >> + clock-names = "fin_pll", "mct"; >> + >> + mct_map: mct-map { >> + #interrupt-cells = <1>; >> + #address-cells = <0>; >> + #size-cells = <0>; >> + interrupt-map = <0 &gic 0 112 0>, >> + <1 &gic 0 113 0>, >> + <2 &gic 0 114 0>, >> + <3 &gic 0 115 0>, >> + <4 &gic 0 116 0>, >> + <5 &gic 0 117 0>, >> + <6 &gic 0 118 0>, >> + <7 &gic 0 119 0>, >> + <8 &gic 0 120 0>, >> + <9 &gic 0 121 0>, >> + <10 &gic 0 122 0>, >> + <11 &gic 0 123 0>; >> + }; >> + }; > > I don't see why need the map here. Why can't we describe the GIC > interrupts directly? Right, it was not required. Also, we will try and use only arch timer and not MCT. > > [...] > >> + timer { >> + compatible = "arm,armv8-timer"; >> + interrupts = <1 13 0xff01>, >> + <1 14 0xff01>, >> + <1 11 0xff01>, >> + <1 10 0xff01>; >> + clock-frequency = <24000000>; > > Your firmware/bootloader should configure CNTFRQ, and this shouldn't be > necessary. The clock-frequency property is an incomplete workaround for > broken firmware that in an ideal world we could kill off. > >> + use-clocksource-only; >> + use-physical-timer; > > Neither of these properties were introduced by this series, and no > rationale was given. > > What are these properties for, and why do you believe they are > necessary? Sorry, that was a mistake. This has been fixed. > > Thanks, > Mark. Thanks. -- Shine bright, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-27 11:30 ` Tomasz Figa -1 siblings, 0 replies; 84+ messages in thread From: Tomasz Figa @ 2014-08-27 11:30 UTC (permalink / raw) To: Naveen Krishna Chatradhi, catalin.marinas Cc: naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Hi Naveen, Please see my comments inline. On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: > Add initial device tree nodes for EXYNOS7 SoC. > Also, includes the dt-binding definitions for clock ids. > > Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> > Cc: Thomas Abraham <thomas.ab@samsung.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 553 insertions(+) > create mode 100644 arch/arm64/boot/dts/exynos7.dtsi > > diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi > new file mode 100644 > index 0000000..6b9eaf4 > --- /dev/null > +++ b/arch/arm64/boot/dts/exynos7.dtsi > @@ -0,0 +1,553 @@ > +/* > + * SAMSUNG EXYNOS7 SoC device tree source > + * > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. > + * EXYNOS7 based board files can include this file and provide > + * values for board specfic bindings. > + * > + * 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 <dt-bindings/clock/exynos7-clk.h> > + > +/ { > + compatible = "samsung,exynos7"; > + interrupt-parent = <&gic>; > + #address-cells = <1>; > + #size-cells = <1>; > + > + aliases { > + pinctrl0 = &pinctrl_0; > + pinctrl1 = &pinctrl_1; > + pinctrl2 = &pinctrl_2; > + pinctrl3 = &pinctrl_3; > + pinctrl4 = &pinctrl_4; > + pinctrl5 = &pinctrl_5; > + pinctrl6 = &pinctrl_6; > + pinctrl7 = &pinctrl_7; > + pinctrl8 = &pinctrl_8; > + pinctrl9 = &pinctrl_9; > + mshc0 = &mmc_0; > + mshc2 = &mmc_2; Please add aliases for serial controllers. Refer to relevant DT binding documentation for more information. > + }; > + > + chipid@10000000 { > + compatible = "samsung,exynos4210-chipid"; > + reg = <0x10000000 0x100>; > + }; Please put SoC components (except cpus node) under a simple-bus node called "soc". Please see exynos5260.dtsi as an example. > + > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57", "arm,armv8"; > + reg = <0x0 0x0>; > + }; Does this SoC really has only one CPU or this is a workaround for things like missing CPU bring-up code? > + }; [snip] > + mct@101C0000 { > + compatible = "samsung,exynos4210-mct"; > + reg = <0x101C0000 0x800>; > + interrupt-controller; > + #interrupt-cells = <1>; MCT is not an interrupt controller. > + interrupt-parent = <&mct_map>; > + interrupts = <0>, <1>, <2>, <3>, > + <4>, <5>, <6>, <7>, > + <8>, <9>, <10>, <11>; > + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>; > + clock-names = "fin_pll", "mct"; > + > + mct_map: mct-map { > + #interrupt-cells = <1>; > + #address-cells = <0>; > + #size-cells = <0>; > + interrupt-map = <0 &gic 0 112 0>, > + <1 &gic 0 113 0>, > + <2 &gic 0 114 0>, > + <3 &gic 0 115 0>, > + <4 &gic 0 116 0>, > + <5 &gic 0 117 0>, > + <6 &gic 0 118 0>, > + <7 &gic 0 119 0>, > + <8 &gic 0 120 0>, > + <9 &gic 0 121 0>, > + <10 &gic 0 122 0>, > + <11 &gic 0 123 0>; All inputs of this interrupt map come from the same interrupt controller. What's the point of this map then? > + }; > + }; > + > + mmc_0: mmc@15740000 { > + compatible = "samsung,exynos7-dw-mshc-smu"; > + interrupts = <0 201 0>; > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0x15740000 0x2000>; > + clocks = <&clock_fsys1 ACLK_MMC0>, > + <&clock_top1 CLK_SCLK_MMC0>; > + clock-names = "biu", "ciu"; > + fifo-depth = <0x40>; > + status = "disabled"; > + }; > + > + mmc_2: mmc@15560000 { > + compatible = "samsung,exynos7-dw-mshc-smu"; > + interrupts = <0 216 0>; > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0x15560000 0x2000>; > + clocks = <&clock_fsys0 ACLK_MMC2>, > + <&clock_top1 CLK_SCLK_MMC2>; > + clock-names = "biu", "ciu"; > + fifo-depth = <0x40>; > + status = "disabled"; > + }; > + > + pinctrl_0: pinctrl@10580000 { > + compatible = "samsung,exynos7-pinctrl"; > + reg = <0x10580000 0x1000>; > + interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, > + <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, > + <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, > + <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>; According to patch 5/14, this bank supports only wake-up interrupts. Their interrupt specifiers should be specified either in the wake-up interrupt controller node (for muxed wake-up interrupts) or in nodes of respective banks (for direct wake-up interrupts). > + wakeup-interrupt-controller { > + compatible = "samsung,exynos4210-wakeup-eint"; > + interrupt-parent = <&gic>; > + interrupts = <0 16 0>; > + }; > + }; [snip] > + serial@13630000 { > + compatible = "samsung,exynos4210-uart"; > + reg = <0x13630000 0x100>; > + interrupts = <0 440 0>; > + clocks = <&clock_peric0 PCLK_UART0>, <&clock_peric0 SCLK_UART0>; > + clock-names = "uart", "clk_uart_baud0"; > + status = "okay"; No need to explicitly specify the status as "okay" in top level dtsi file. > + }; > + > + serial@14C20000 { > + compatible = "samsung,exynos4210-uart"; > + reg = <0x14C20000 0x100>; > + interrupts = <0 456 0>; > + clocks = <&clock_peric1 PCLK_UART1>, <&clock_peric1 SCLK_UART1>; > + clock-names = "uart", "clk_uart_baud1"; The "clk_uart_baud1" clock doesn't seem right. The N in "clk_uart_baudN" stands for the input of internal clock source mux, not index of the IP block in the SoC. Please make sure this is defined correctly. > + status = "okay"; Ditto. > + }; > + > + serial@14C30000 { > + compatible = "samsung,exynos4210-uart"; > + reg = <0x14C30000 0x100>; > + interrupts = <0 457 0>; > + clocks = <&clock_peric1 PCLK_UART2>, <&clock_peric1 SCLK_UART2>; > + clock-names = "uart", "clk_uart_baud2"; Ditto. > + status = "okay"; Ditto. > + }; > + > + serial@14C40000 { > + compatible = "samsung,exynos4210-uart"; > + reg = <0x14C40000 0x100>; > + interrupts = <0 458 0>; > + clocks = <&clock_peric1 PCLK_UART3>, <&clock_peric1 SCLK_UART3>; > + clock-names = "uart", "clk_uart_baud3"; Ditto. > + status = "okay"; Ditto. Best regards, Tomasz ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-27 11:30 ` Tomasz Figa 0 siblings, 0 replies; 84+ messages in thread From: Tomasz Figa @ 2014-08-27 11:30 UTC (permalink / raw) To: linux-arm-kernel Hi Naveen, Please see my comments inline. On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: > Add initial device tree nodes for EXYNOS7 SoC. > Also, includes the dt-binding definitions for clock ids. > > Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> > Cc: Thomas Abraham <thomas.ab@samsung.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 553 insertions(+) > create mode 100644 arch/arm64/boot/dts/exynos7.dtsi > > diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi > new file mode 100644 > index 0000000..6b9eaf4 > --- /dev/null > +++ b/arch/arm64/boot/dts/exynos7.dtsi > @@ -0,0 +1,553 @@ > +/* > + * SAMSUNG EXYNOS7 SoC device tree source > + * > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. > + * EXYNOS7 based board files can include this file and provide > + * values for board specfic bindings. > + * > + * 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 <dt-bindings/clock/exynos7-clk.h> > + > +/ { > + compatible = "samsung,exynos7"; > + interrupt-parent = <&gic>; > + #address-cells = <1>; > + #size-cells = <1>; > + > + aliases { > + pinctrl0 = &pinctrl_0; > + pinctrl1 = &pinctrl_1; > + pinctrl2 = &pinctrl_2; > + pinctrl3 = &pinctrl_3; > + pinctrl4 = &pinctrl_4; > + pinctrl5 = &pinctrl_5; > + pinctrl6 = &pinctrl_6; > + pinctrl7 = &pinctrl_7; > + pinctrl8 = &pinctrl_8; > + pinctrl9 = &pinctrl_9; > + mshc0 = &mmc_0; > + mshc2 = &mmc_2; Please add aliases for serial controllers. Refer to relevant DT binding documentation for more information. > + }; > + > + chipid at 10000000 { > + compatible = "samsung,exynos4210-chipid"; > + reg = <0x10000000 0x100>; > + }; Please put SoC components (except cpus node) under a simple-bus node called "soc". Please see exynos5260.dtsi as an example. > + > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + cpu at 0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57", "arm,armv8"; > + reg = <0x0 0x0>; > + }; Does this SoC really has only one CPU or this is a workaround for things like missing CPU bring-up code? > + }; [snip] > + mct at 101C0000 { > + compatible = "samsung,exynos4210-mct"; > + reg = <0x101C0000 0x800>; > + interrupt-controller; > + #interrupt-cells = <1>; MCT is not an interrupt controller. > + interrupt-parent = <&mct_map>; > + interrupts = <0>, <1>, <2>, <3>, > + <4>, <5>, <6>, <7>, > + <8>, <9>, <10>, <11>; > + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>; > + clock-names = "fin_pll", "mct"; > + > + mct_map: mct-map { > + #interrupt-cells = <1>; > + #address-cells = <0>; > + #size-cells = <0>; > + interrupt-map = <0 &gic 0 112 0>, > + <1 &gic 0 113 0>, > + <2 &gic 0 114 0>, > + <3 &gic 0 115 0>, > + <4 &gic 0 116 0>, > + <5 &gic 0 117 0>, > + <6 &gic 0 118 0>, > + <7 &gic 0 119 0>, > + <8 &gic 0 120 0>, > + <9 &gic 0 121 0>, > + <10 &gic 0 122 0>, > + <11 &gic 0 123 0>; All inputs of this interrupt map come from the same interrupt controller. What's the point of this map then? > + }; > + }; > + > + mmc_0: mmc at 15740000 { > + compatible = "samsung,exynos7-dw-mshc-smu"; > + interrupts = <0 201 0>; > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0x15740000 0x2000>; > + clocks = <&clock_fsys1 ACLK_MMC0>, > + <&clock_top1 CLK_SCLK_MMC0>; > + clock-names = "biu", "ciu"; > + fifo-depth = <0x40>; > + status = "disabled"; > + }; > + > + mmc_2: mmc at 15560000 { > + compatible = "samsung,exynos7-dw-mshc-smu"; > + interrupts = <0 216 0>; > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0x15560000 0x2000>; > + clocks = <&clock_fsys0 ACLK_MMC2>, > + <&clock_top1 CLK_SCLK_MMC2>; > + clock-names = "biu", "ciu"; > + fifo-depth = <0x40>; > + status = "disabled"; > + }; > + > + pinctrl_0: pinctrl at 10580000 { > + compatible = "samsung,exynos7-pinctrl"; > + reg = <0x10580000 0x1000>; > + interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, > + <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, > + <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, > + <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>; According to patch 5/14, this bank supports only wake-up interrupts. Their interrupt specifiers should be specified either in the wake-up interrupt controller node (for muxed wake-up interrupts) or in nodes of respective banks (for direct wake-up interrupts). > + wakeup-interrupt-controller { > + compatible = "samsung,exynos4210-wakeup-eint"; > + interrupt-parent = <&gic>; > + interrupts = <0 16 0>; > + }; > + }; [snip] > + serial at 13630000 { > + compatible = "samsung,exynos4210-uart"; > + reg = <0x13630000 0x100>; > + interrupts = <0 440 0>; > + clocks = <&clock_peric0 PCLK_UART0>, <&clock_peric0 SCLK_UART0>; > + clock-names = "uart", "clk_uart_baud0"; > + status = "okay"; No need to explicitly specify the status as "okay" in top level dtsi file. > + }; > + > + serial at 14C20000 { > + compatible = "samsung,exynos4210-uart"; > + reg = <0x14C20000 0x100>; > + interrupts = <0 456 0>; > + clocks = <&clock_peric1 PCLK_UART1>, <&clock_peric1 SCLK_UART1>; > + clock-names = "uart", "clk_uart_baud1"; The "clk_uart_baud1" clock doesn't seem right. The N in "clk_uart_baudN" stands for the input of internal clock source mux, not index of the IP block in the SoC. Please make sure this is defined correctly. > + status = "okay"; Ditto. > + }; > + > + serial at 14C30000 { > + compatible = "samsung,exynos4210-uart"; > + reg = <0x14C30000 0x100>; > + interrupts = <0 457 0>; > + clocks = <&clock_peric1 PCLK_UART2>, <&clock_peric1 SCLK_UART2>; > + clock-names = "uart", "clk_uart_baud2"; Ditto. > + status = "okay"; Ditto. > + }; > + > + serial at 14C40000 { > + compatible = "samsung,exynos4210-uart"; > + reg = <0x14C40000 0x100>; > + interrupts = <0 458 0>; > + clocks = <&clock_peric1 PCLK_UART3>, <&clock_peric1 SCLK_UART3>; > + clock-names = "uart", "clk_uart_baud3"; Ditto. > + status = "okay"; Ditto. Best regards, Tomasz ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-27 11:30 ` Tomasz Figa @ 2014-09-03 7:55 ` Naveen Krishna Ch -1 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-09-03 7:55 UTC (permalink / raw) To: tomasz.figa Cc: Naveen Krishna Chatradhi, catalin.marinas, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Hi Tomasz, On 27 August 2014 17:00, Tomasz Figa <t.figa@samsung.com> wrote: > Hi Naveen, > > Please see my comments inline. > > On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: >> Add initial device tree nodes for EXYNOS7 SoC. >> Also, includes the dt-binding definitions for clock ids. >> >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Thomas Abraham <thomas.ab@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 553 insertions(+) >> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi >> >> diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi >> new file mode 100644 >> index 0000000..6b9eaf4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/exynos7.dtsi >> @@ -0,0 +1,553 @@ >> +/* >> + * SAMSUNG EXYNOS7 SoC device tree source >> + * >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. >> + * EXYNOS7 based board files can include this file and provide >> + * values for board specfic bindings. >> + * >> + * 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 <dt-bindings/clock/exynos7-clk.h> >> + >> +/ { >> + compatible = "samsung,exynos7"; >> + interrupt-parent = <&gic>; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + >> + aliases { >> + pinctrl0 = &pinctrl_0; >> + pinctrl1 = &pinctrl_1; >> + pinctrl2 = &pinctrl_2; >> + pinctrl3 = &pinctrl_3; >> + pinctrl4 = &pinctrl_4; >> + pinctrl5 = &pinctrl_5; >> + pinctrl6 = &pinctrl_6; >> + pinctrl7 = &pinctrl_7; >> + pinctrl8 = &pinctrl_8; >> + pinctrl9 = &pinctrl_9; >> + mshc0 = &mmc_0; >> + mshc2 = &mmc_2; > > Please add aliases for serial controllers. Refer to relevant DT binding > documentation for more information. Ok. > >> + }; >> + >> + chipid@10000000 { >> + compatible = "samsung,exynos4210-chipid"; >> + reg = <0x10000000 0x100>; >> + }; > > Please put SoC components (except cpus node) under a simple-bus node > called "soc". Please see exynos5260.dtsi as an example. Ok. > >> + >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; >> + >> + cpu@0 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a57", "arm,armv8"; >> + reg = <0x0 0x0>; >> + }; > > Does this SoC really has only one CPU or this is a workaround for things > like missing CPU bring-up code? > >> + }; > > [snip] > >> + mct@101C0000 { >> + compatible = "samsung,exynos4210-mct"; >> + reg = <0x101C0000 0x800>; >> + interrupt-controller; >> + #interrupt-cells = <1>; > > MCT is not an interrupt controller. > >> + interrupt-parent = <&mct_map>; >> + interrupts = <0>, <1>, <2>, <3>, >> + <4>, <5>, <6>, <7>, >> + <8>, <9>, <10>, <11>; >> + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>; >> + clock-names = "fin_pll", "mct"; >> + >> + mct_map: mct-map { >> + #interrupt-cells = <1>; >> + #address-cells = <0>; >> + #size-cells = <0>; >> + interrupt-map = <0 &gic 0 112 0>, >> + <1 &gic 0 113 0>, >> + <2 &gic 0 114 0>, >> + <3 &gic 0 115 0>, >> + <4 &gic 0 116 0>, >> + <5 &gic 0 117 0>, >> + <6 &gic 0 118 0>, >> + <7 &gic 0 119 0>, >> + <8 &gic 0 120 0>, >> + <9 &gic 0 121 0>, >> + <10 &gic 0 122 0>, >> + <11 &gic 0 123 0>; > > All inputs of this interrupt map come from the same interrupt > controller. What's the point of this map then? > >> + }; >> + }; >> + >> + mmc_0: mmc@15740000 { >> + compatible = "samsung,exynos7-dw-mshc-smu"; >> + interrupts = <0 201 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + reg = <0x15740000 0x2000>; >> + clocks = <&clock_fsys1 ACLK_MMC0>, >> + <&clock_top1 CLK_SCLK_MMC0>; >> + clock-names = "biu", "ciu"; >> + fifo-depth = <0x40>; >> + status = "disabled"; >> + }; >> + >> + mmc_2: mmc@15560000 { >> + compatible = "samsung,exynos7-dw-mshc-smu"; >> + interrupts = <0 216 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + reg = <0x15560000 0x2000>; >> + clocks = <&clock_fsys0 ACLK_MMC2>, >> + <&clock_top1 CLK_SCLK_MMC2>; >> + clock-names = "biu", "ciu"; >> + fifo-depth = <0x40>; >> + status = "disabled"; >> + }; >> + >> + pinctrl_0: pinctrl@10580000 { >> + compatible = "samsung,exynos7-pinctrl"; >> + reg = <0x10580000 0x1000>; >> + interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, >> + <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, >> + <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, >> + <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>; > > According to patch 5/14, this bank supports only wake-up interrupts. > Their interrupt specifiers should be specified either in the wake-up > interrupt controller node (for muxed wake-up interrupts) or in nodes of > respective banks (for direct wake-up interrupts). Ok, will fix. > >> + wakeup-interrupt-controller { >> + compatible = "samsung,exynos4210-wakeup-eint"; >> + interrupt-parent = <&gic>; >> + interrupts = <0 16 0>; >> + }; >> + }; > > [snip] > >> + serial@13630000 { >> + compatible = "samsung,exynos4210-uart"; >> + reg = <0x13630000 0x100>; >> + interrupts = <0 440 0>; >> + clocks = <&clock_peric0 PCLK_UART0>, <&clock_peric0 SCLK_UART0>; >> + clock-names = "uart", "clk_uart_baud0"; >> + status = "okay"; > > No need to explicitly specify the status as "okay" in top level dtsi file. Ok. Fixed. > >> + }; >> + >> + serial@14C20000 { >> + compatible = "samsung,exynos4210-uart"; >> + reg = <0x14C20000 0x100>; >> + interrupts = <0 456 0>; >> + clocks = <&clock_peric1 PCLK_UART1>, <&clock_peric1 SCLK_UART1>; >> + clock-names = "uart", "clk_uart_baud1"; > > The "clk_uart_baud1" clock doesn't seem right. The N in "clk_uart_baudN" > stands for the input of internal clock source mux, not index of the IP > block in the SoC. Please make sure this is defined correctly. Right. That was a mistake. This is fixed. > >> + status = "okay"; > > Ditto. > >> + }; >> + >> + serial@14C30000 { >> + compatible = "samsung,exynos4210-uart"; >> + reg = <0x14C30000 0x100>; >> + interrupts = <0 457 0>; >> + clocks = <&clock_peric1 PCLK_UART2>, <&clock_peric1 SCLK_UART2>; >> + clock-names = "uart", "clk_uart_baud2"; > > Ditto. > >> + status = "okay"; > > Ditto. > >> + }; >> + >> + serial@14C40000 { >> + compatible = "samsung,exynos4210-uart"; >> + reg = <0x14C40000 0x100>; >> + interrupts = <0 458 0>; >> + clocks = <&clock_peric1 PCLK_UART3>, <&clock_peric1 SCLK_UART3>; >> + clock-names = "uart", "clk_uart_baud3"; > > Ditto. > >> + status = "okay"; > > Ditto. > > Best regards, > Tomasz Thanks for your comments. -- Shine bright, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-09-03 7:55 ` Naveen Krishna Ch 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-09-03 7:55 UTC (permalink / raw) To: linux-arm-kernel Hi Tomasz, On 27 August 2014 17:00, Tomasz Figa <t.figa@samsung.com> wrote: > Hi Naveen, > > Please see my comments inline. > > On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: >> Add initial device tree nodes for EXYNOS7 SoC. >> Also, includes the dt-binding definitions for clock ids. >> >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Thomas Abraham <thomas.ab@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 553 insertions(+) >> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi >> >> diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi >> new file mode 100644 >> index 0000000..6b9eaf4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/exynos7.dtsi >> @@ -0,0 +1,553 @@ >> +/* >> + * SAMSUNG EXYNOS7 SoC device tree source >> + * >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. >> + * EXYNOS7 based board files can include this file and provide >> + * values for board specfic bindings. >> + * >> + * 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 <dt-bindings/clock/exynos7-clk.h> >> + >> +/ { >> + compatible = "samsung,exynos7"; >> + interrupt-parent = <&gic>; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + >> + aliases { >> + pinctrl0 = &pinctrl_0; >> + pinctrl1 = &pinctrl_1; >> + pinctrl2 = &pinctrl_2; >> + pinctrl3 = &pinctrl_3; >> + pinctrl4 = &pinctrl_4; >> + pinctrl5 = &pinctrl_5; >> + pinctrl6 = &pinctrl_6; >> + pinctrl7 = &pinctrl_7; >> + pinctrl8 = &pinctrl_8; >> + pinctrl9 = &pinctrl_9; >> + mshc0 = &mmc_0; >> + mshc2 = &mmc_2; > > Please add aliases for serial controllers. Refer to relevant DT binding > documentation for more information. Ok. > >> + }; >> + >> + chipid at 10000000 { >> + compatible = "samsung,exynos4210-chipid"; >> + reg = <0x10000000 0x100>; >> + }; > > Please put SoC components (except cpus node) under a simple-bus node > called "soc". Please see exynos5260.dtsi as an example. Ok. > >> + >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; >> + >> + cpu at 0 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a57", "arm,armv8"; >> + reg = <0x0 0x0>; >> + }; > > Does this SoC really has only one CPU or this is a workaround for things > like missing CPU bring-up code? > >> + }; > > [snip] > >> + mct at 101C0000 { >> + compatible = "samsung,exynos4210-mct"; >> + reg = <0x101C0000 0x800>; >> + interrupt-controller; >> + #interrupt-cells = <1>; > > MCT is not an interrupt controller. > >> + interrupt-parent = <&mct_map>; >> + interrupts = <0>, <1>, <2>, <3>, >> + <4>, <5>, <6>, <7>, >> + <8>, <9>, <10>, <11>; >> + clocks = <&fin_pll>, <&clock_peris PCLK_MCT>; >> + clock-names = "fin_pll", "mct"; >> + >> + mct_map: mct-map { >> + #interrupt-cells = <1>; >> + #address-cells = <0>; >> + #size-cells = <0>; >> + interrupt-map = <0 &gic 0 112 0>, >> + <1 &gic 0 113 0>, >> + <2 &gic 0 114 0>, >> + <3 &gic 0 115 0>, >> + <4 &gic 0 116 0>, >> + <5 &gic 0 117 0>, >> + <6 &gic 0 118 0>, >> + <7 &gic 0 119 0>, >> + <8 &gic 0 120 0>, >> + <9 &gic 0 121 0>, >> + <10 &gic 0 122 0>, >> + <11 &gic 0 123 0>; > > All inputs of this interrupt map come from the same interrupt > controller. What's the point of this map then? > >> + }; >> + }; >> + >> + mmc_0: mmc at 15740000 { >> + compatible = "samsung,exynos7-dw-mshc-smu"; >> + interrupts = <0 201 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + reg = <0x15740000 0x2000>; >> + clocks = <&clock_fsys1 ACLK_MMC0>, >> + <&clock_top1 CLK_SCLK_MMC0>; >> + clock-names = "biu", "ciu"; >> + fifo-depth = <0x40>; >> + status = "disabled"; >> + }; >> + >> + mmc_2: mmc at 15560000 { >> + compatible = "samsung,exynos7-dw-mshc-smu"; >> + interrupts = <0 216 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + reg = <0x15560000 0x2000>; >> + clocks = <&clock_fsys0 ACLK_MMC2>, >> + <&clock_top1 CLK_SCLK_MMC2>; >> + clock-names = "biu", "ciu"; >> + fifo-depth = <0x40>; >> + status = "disabled"; >> + }; >> + >> + pinctrl_0: pinctrl at 10580000 { >> + compatible = "samsung,exynos7-pinctrl"; >> + reg = <0x10580000 0x1000>; >> + interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, >> + <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, >> + <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, >> + <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>; > > According to patch 5/14, this bank supports only wake-up interrupts. > Their interrupt specifiers should be specified either in the wake-up > interrupt controller node (for muxed wake-up interrupts) or in nodes of > respective banks (for direct wake-up interrupts). Ok, will fix. > >> + wakeup-interrupt-controller { >> + compatible = "samsung,exynos4210-wakeup-eint"; >> + interrupt-parent = <&gic>; >> + interrupts = <0 16 0>; >> + }; >> + }; > > [snip] > >> + serial at 13630000 { >> + compatible = "samsung,exynos4210-uart"; >> + reg = <0x13630000 0x100>; >> + interrupts = <0 440 0>; >> + clocks = <&clock_peric0 PCLK_UART0>, <&clock_peric0 SCLK_UART0>; >> + clock-names = "uart", "clk_uart_baud0"; >> + status = "okay"; > > No need to explicitly specify the status as "okay" in top level dtsi file. Ok. Fixed. > >> + }; >> + >> + serial at 14C20000 { >> + compatible = "samsung,exynos4210-uart"; >> + reg = <0x14C20000 0x100>; >> + interrupts = <0 456 0>; >> + clocks = <&clock_peric1 PCLK_UART1>, <&clock_peric1 SCLK_UART1>; >> + clock-names = "uart", "clk_uart_baud1"; > > The "clk_uart_baud1" clock doesn't seem right. The N in "clk_uart_baudN" > stands for the input of internal clock source mux, not index of the IP > block in the SoC. Please make sure this is defined correctly. Right. That was a mistake. This is fixed. > >> + status = "okay"; > > Ditto. > >> + }; >> + >> + serial at 14C30000 { >> + compatible = "samsung,exynos4210-uart"; >> + reg = <0x14C30000 0x100>; >> + interrupts = <0 457 0>; >> + clocks = <&clock_peric1 PCLK_UART2>, <&clock_peric1 SCLK_UART2>; >> + clock-names = "uart", "clk_uart_baud2"; > > Ditto. > >> + status = "okay"; > > Ditto. > >> + }; >> + >> + serial at 14C40000 { >> + compatible = "samsung,exynos4210-uart"; >> + reg = <0x14C40000 0x100>; >> + interrupts = <0 458 0>; >> + clocks = <&clock_peric1 PCLK_UART3>, <&clock_peric1 SCLK_UART3>; >> + clock-names = "uart", "clk_uart_baud3"; > > Ditto. > >> + status = "okay"; > > Ditto. > > Best regards, > Tomasz Thanks for your comments. -- Shine bright, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-28 3:56 ` Olof Johansson -1 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 3:56 UTC (permalink / raw) To: Naveen Krishna Chatradhi Cc: catalin.marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Hi, On Wed, Aug 27, 2014 at 03:14:18PM +0530, Naveen Krishna Chatradhi wrote: > Add initial device tree nodes for EXYNOS7 SoC. > Also, includes the dt-binding definitions for clock ids. Uh, no -- it just adds the dtsi. > Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> > Cc: Thomas Abraham <thomas.ab@samsung.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 553 insertions(+) > create mode 100644 arch/arm64/boot/dts/exynos7.dtsi > > diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi > new file mode 100644 > index 0000000..6b9eaf4 > --- /dev/null > +++ b/arch/arm64/boot/dts/exynos7.dtsi Let's not make the same mistake as on 32-bit, and go with a directory hierarchy here from day one. So, please create a exynos subdirectory for this file. You also need a Makefile when you add a board dts. > @@ -0,0 +1,553 @@ > +/* > + * SAMSUNG EXYNOS7 SoC device tree source > + * > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. > + * EXYNOS7 based board files can include this file and provide > + * values for board specfic bindings. > + * > + * 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 <dt-bindings/clock/exynos7-clk.h> > + > +/ { > + compatible = "samsung,exynos7"; > + interrupt-parent = <&gic>; > + #address-cells = <1>; > + #size-cells = <1>; You should probably use address-cells/size-cells 2/2 on a 64-bit platform. > + aliases { > + pinctrl0 = &pinctrl_0; > + pinctrl1 = &pinctrl_1; > + pinctrl2 = &pinctrl_2; > + pinctrl3 = &pinctrl_3; > + pinctrl4 = &pinctrl_4; > + pinctrl5 = &pinctrl_5; > + pinctrl6 = &pinctrl_6; > + pinctrl7 = &pinctrl_7; > + pinctrl8 = &pinctrl_8; > + pinctrl9 = &pinctrl_9; > + mshc0 = &mmc_0; > + mshc2 = &mmc_2; > + }; > + > + chipid@10000000 { > + compatible = "samsung,exynos4210-chipid"; > + reg = <0x10000000 0x100>; > + }; > + > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; Why size-cells=2? Can you not fit a cpuid in 32 bits? > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57", "arm,armv8"; > + reg = <0x0 0x0>; > + }; > + }; > + > + fin_pll: xxti { > + compatible = "fixed-clock"; > + clock-frequency = <24000000>; > + clock-output-names = "fin_pll"; > + #clock-cells = <0>; > + }; > + > + gic: interrupt-controller@11001000 { > + compatible = "arm,gic-400"; > + #interrupt-cells = <3>; > + #address-cells = <0>; > + interrupt-controller; > + reg = <0x11001000 0x1000>, > + <0x11002000 0x1000>, > + <0x11004000 0x2000>, > + <0x11006000 0x2000>; > + }; > + > + hsi2c_0: hsi2c@13640000 { > + compatible = "samsung,exynos7-hsi2c"; Is the i2c controller here completely new? Also, please use 'i2c' for node name on these nodes. > + reg = <0x13640000 0x1000>; > + interrupts = <0 441 0>; > + #address-cells = <1>; > + #size-cells = <0>; > + pinctrl-names = "default"; > + pinctrl-0 = <&hs_i2c0_bus>; > + clocks = <&clock_peric0 PCLK_HSI2C0>; > + clock-names = "hsi2c"; > + status = "disabled"; > + }; > + > + hsi2c_1: hsi2c@13650000 { > + compatible = "samsung,exynos7-hsi2c"; > + reg = <0x13650000 0x1000>; > + interrupts = <0 442 0>; > + #address-cells = <1>; > + #size-cells = <0>; > + pinctrl-names = "default"; > + pinctrl-0 = <&hs_i2c1_bus>; > + clocks = <&clock_peric0 PCLK_HSI2C1>; > + clock-names = "hsi2c"; > + status = "disabled"; > + }; > + > + hsi2c_2: hsi2c@14E60000 { I much prefer lowercase hex in unit addresses (and reg entries) below. I know 32-bit uses uppercase, but let's switch going forward here. > + mct@101C0000 { > + compatible = "samsung,exynos4210-mct"; Please just do away with MCT here, and use architected timers going forward. There really shouldn't be a need to keep supporting MCT any more -- it's a construct from before arch timers on Cortex-A9. > + mmc_0: mmc@15740000 { > + compatible = "samsung,exynos7-dw-mshc-smu"; Is this controller backwards compatible with exynos5 ones? > + /* The Clock nodes are ordered as per the usermanual. */ "The clock" "user manual" > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <1 13 0xff01>, > + <1 14 0xff01>, > + <1 11 0xff01>, > + <1 10 0xff01>; > + clock-frequency = <24000000>; > + use-clocksource-only; > + use-physical-timer; These two properties are not standard, and I would expect any 64-bit platform to come with PSCI such that you have a way to initialize the virtual timers. -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 3:56 ` Olof Johansson 0 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 3:56 UTC (permalink / raw) To: linux-arm-kernel Hi, On Wed, Aug 27, 2014 at 03:14:18PM +0530, Naveen Krishna Chatradhi wrote: > Add initial device tree nodes for EXYNOS7 SoC. > Also, includes the dt-binding definitions for clock ids. Uh, no -- it just adds the dtsi. > Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> > Cc: Thomas Abraham <thomas.ab@samsung.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 553 insertions(+) > create mode 100644 arch/arm64/boot/dts/exynos7.dtsi > > diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi > new file mode 100644 > index 0000000..6b9eaf4 > --- /dev/null > +++ b/arch/arm64/boot/dts/exynos7.dtsi Let's not make the same mistake as on 32-bit, and go with a directory hierarchy here from day one. So, please create a exynos subdirectory for this file. You also need a Makefile when you add a board dts. > @@ -0,0 +1,553 @@ > +/* > + * SAMSUNG EXYNOS7 SoC device tree source > + * > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. > + * EXYNOS7 based board files can include this file and provide > + * values for board specfic bindings. > + * > + * 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 <dt-bindings/clock/exynos7-clk.h> > + > +/ { > + compatible = "samsung,exynos7"; > + interrupt-parent = <&gic>; > + #address-cells = <1>; > + #size-cells = <1>; You should probably use address-cells/size-cells 2/2 on a 64-bit platform. > + aliases { > + pinctrl0 = &pinctrl_0; > + pinctrl1 = &pinctrl_1; > + pinctrl2 = &pinctrl_2; > + pinctrl3 = &pinctrl_3; > + pinctrl4 = &pinctrl_4; > + pinctrl5 = &pinctrl_5; > + pinctrl6 = &pinctrl_6; > + pinctrl7 = &pinctrl_7; > + pinctrl8 = &pinctrl_8; > + pinctrl9 = &pinctrl_9; > + mshc0 = &mmc_0; > + mshc2 = &mmc_2; > + }; > + > + chipid at 10000000 { > + compatible = "samsung,exynos4210-chipid"; > + reg = <0x10000000 0x100>; > + }; > + > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; Why size-cells=2? Can you not fit a cpuid in 32 bits? > + cpu at 0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57", "arm,armv8"; > + reg = <0x0 0x0>; > + }; > + }; > + > + fin_pll: xxti { > + compatible = "fixed-clock"; > + clock-frequency = <24000000>; > + clock-output-names = "fin_pll"; > + #clock-cells = <0>; > + }; > + > + gic: interrupt-controller at 11001000 { > + compatible = "arm,gic-400"; > + #interrupt-cells = <3>; > + #address-cells = <0>; > + interrupt-controller; > + reg = <0x11001000 0x1000>, > + <0x11002000 0x1000>, > + <0x11004000 0x2000>, > + <0x11006000 0x2000>; > + }; > + > + hsi2c_0: hsi2c at 13640000 { > + compatible = "samsung,exynos7-hsi2c"; Is the i2c controller here completely new? Also, please use 'i2c' for node name on these nodes. > + reg = <0x13640000 0x1000>; > + interrupts = <0 441 0>; > + #address-cells = <1>; > + #size-cells = <0>; > + pinctrl-names = "default"; > + pinctrl-0 = <&hs_i2c0_bus>; > + clocks = <&clock_peric0 PCLK_HSI2C0>; > + clock-names = "hsi2c"; > + status = "disabled"; > + }; > + > + hsi2c_1: hsi2c at 13650000 { > + compatible = "samsung,exynos7-hsi2c"; > + reg = <0x13650000 0x1000>; > + interrupts = <0 442 0>; > + #address-cells = <1>; > + #size-cells = <0>; > + pinctrl-names = "default"; > + pinctrl-0 = <&hs_i2c1_bus>; > + clocks = <&clock_peric0 PCLK_HSI2C1>; > + clock-names = "hsi2c"; > + status = "disabled"; > + }; > + > + hsi2c_2: hsi2c at 14E60000 { I much prefer lowercase hex in unit addresses (and reg entries) below. I know 32-bit uses uppercase, but let's switch going forward here. > + mct at 101C0000 { > + compatible = "samsung,exynos4210-mct"; Please just do away with MCT here, and use architected timers going forward. There really shouldn't be a need to keep supporting MCT any more -- it's a construct from before arch timers on Cortex-A9. > + mmc_0: mmc at 15740000 { > + compatible = "samsung,exynos7-dw-mshc-smu"; Is this controller backwards compatible with exynos5 ones? > + /* The Clock nodes are ordered as per the usermanual. */ "The clock" "user manual" > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <1 13 0xff01>, > + <1 14 0xff01>, > + <1 11 0xff01>, > + <1 10 0xff01>; > + clock-frequency = <24000000>; > + use-clocksource-only; > + use-physical-timer; These two properties are not standard, and I would expect any 64-bit platform to come with PSCI such that you have a way to initialize the virtual timers. -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 3:56 ` Olof Johansson @ 2014-08-28 8:35 ` Marc Zyngier -1 siblings, 0 replies; 84+ messages in thread From: Marc Zyngier @ 2014-08-28 8:35 UTC (permalink / raw) To: Olof Johansson, Naveen Krishna Chatradhi Cc: devicetree, linux-samsung-soc, Rob Herring, Catalin Marinas, Thomas Abraham, cpgs, naveenkrishna.ch, linux-arm-kernel On 28/08/14 04:56, Olof Johansson wrote: > Hi, > > On Wed, Aug 27, 2014 at 03:14:18PM +0530, Naveen Krishna Chatradhi wrote: >> Add initial device tree nodes for EXYNOS7 SoC. >> Also, includes the dt-binding definitions for clock ids. > > Uh, no -- it just adds the dtsi. > >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Thomas Abraham <thomas.ab@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 553 insertions(+) >> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi >> >> diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi >> new file mode 100644 >> index 0000000..6b9eaf4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/exynos7.dtsi > > Let's not make the same mistake as on 32-bit, and go with a directory > hierarchy here from day one. > > So, please create a exynos subdirectory for this file. You also need > a Makefile when you add a board dts. > >> @@ -0,0 +1,553 @@ >> +/* >> + * SAMSUNG EXYNOS7 SoC device tree source >> + * >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. >> + * EXYNOS7 based board files can include this file and provide >> + * values for board specfic bindings. >> + * >> + * 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 <dt-bindings/clock/exynos7-clk.h> >> + >> +/ { >> + compatible = "samsung,exynos7"; >> + interrupt-parent = <&gic>; >> + #address-cells = <1>; >> + #size-cells = <1>; > > You should probably use address-cells/size-cells 2/2 on a 64-bit platform. > >> + aliases { >> + pinctrl0 = &pinctrl_0; >> + pinctrl1 = &pinctrl_1; >> + pinctrl2 = &pinctrl_2; >> + pinctrl3 = &pinctrl_3; >> + pinctrl4 = &pinctrl_4; >> + pinctrl5 = &pinctrl_5; >> + pinctrl6 = &pinctrl_6; >> + pinctrl7 = &pinctrl_7; >> + pinctrl8 = &pinctrl_8; >> + pinctrl9 = &pinctrl_9; >> + mshc0 = &mmc_0; >> + mshc2 = &mmc_2; >> + }; >> + >> + chipid@10000000 { >> + compatible = "samsung,exynos4210-chipid"; >> + reg = <0x10000000 0x100>; >> + }; >> + >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; > > Why size-cells=2? Can you not fit a cpuid in 32 bits? > >> + cpu@0 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a57", "arm,armv8"; >> + reg = <0x0 0x0>; >> + }; >> + }; >> + >> + fin_pll: xxti { >> + compatible = "fixed-clock"; >> + clock-frequency = <24000000>; >> + clock-output-names = "fin_pll"; >> + #clock-cells = <0>; >> + }; >> + >> + gic: interrupt-controller@11001000 { >> + compatible = "arm,gic-400"; >> + #interrupt-cells = <3>; >> + #address-cells = <0>; >> + interrupt-controller; >> + reg = <0x11001000 0x1000>, >> + <0x11002000 0x1000>, >> + <0x11004000 0x2000>, >> + <0x11006000 0x2000>; >> + }; >> + >> + hsi2c_0: hsi2c@13640000 { >> + compatible = "samsung,exynos7-hsi2c"; > > Is the i2c controller here completely new? > > Also, please use 'i2c' for node name on these nodes. > >> + reg = <0x13640000 0x1000>; >> + interrupts = <0 441 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&hs_i2c0_bus>; >> + clocks = <&clock_peric0 PCLK_HSI2C0>; >> + clock-names = "hsi2c"; >> + status = "disabled"; >> + }; >> + >> + hsi2c_1: hsi2c@13650000 { >> + compatible = "samsung,exynos7-hsi2c"; >> + reg = <0x13650000 0x1000>; >> + interrupts = <0 442 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&hs_i2c1_bus>; >> + clocks = <&clock_peric0 PCLK_HSI2C1>; >> + clock-names = "hsi2c"; >> + status = "disabled"; >> + }; >> + >> + hsi2c_2: hsi2c@14E60000 { > > I much prefer lowercase hex in unit addresses (and reg entries) below. I > know 32-bit uses uppercase, but let's switch going forward here. > >> + mct@101C0000 { >> + compatible = "samsung,exynos4210-mct"; > > Please just do away with MCT here, and use architected timers going > forward. There really shouldn't be a need to keep supporting MCT any > more -- it's a construct from before arch timers on Cortex-A9. > >> + mmc_0: mmc@15740000 { >> + compatible = "samsung,exynos7-dw-mshc-smu"; > > Is this controller backwards compatible with exynos5 ones? > >> + /* The Clock nodes are ordered as per the usermanual. */ > > "The clock" > > "user manual" > >> + timer { >> + compatible = "arm,armv8-timer"; >> + interrupts = <1 13 0xff01>, >> + <1 14 0xff01>, >> + <1 11 0xff01>, >> + <1 10 0xff01>; >> + clock-frequency = <24000000>; >> + use-clocksource-only; >> + use-physical-timer; > > These two properties are not standard, and I would expect any 64-bit > platform to come with PSCI such that you have a way to initialize the > virtual timers. It really sickens me that this is the n-th iteration of a Samsung SoC having the generic timer (basically since the 5250 came out), and still it is littered with stupid firmware bugs: - Broken CNTFRQ (as outlined by the need of clock-frequency) - Broken CNTVOFF (as hinted by the reliance on the physical timer) You would think that after over two years, someone would have a clue and added the missing 4 instructions to the boot ROM. Or not. M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 8:35 ` Marc Zyngier 0 siblings, 0 replies; 84+ messages in thread From: Marc Zyngier @ 2014-08-28 8:35 UTC (permalink / raw) To: linux-arm-kernel On 28/08/14 04:56, Olof Johansson wrote: > Hi, > > On Wed, Aug 27, 2014 at 03:14:18PM +0530, Naveen Krishna Chatradhi wrote: >> Add initial device tree nodes for EXYNOS7 SoC. >> Also, includes the dt-binding definitions for clock ids. > > Uh, no -- it just adds the dtsi. > >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Thomas Abraham <thomas.ab@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 553 insertions(+) >> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi >> >> diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi >> new file mode 100644 >> index 0000000..6b9eaf4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/exynos7.dtsi > > Let's not make the same mistake as on 32-bit, and go with a directory > hierarchy here from day one. > > So, please create a exynos subdirectory for this file. You also need > a Makefile when you add a board dts. > >> @@ -0,0 +1,553 @@ >> +/* >> + * SAMSUNG EXYNOS7 SoC device tree source >> + * >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. >> + * EXYNOS7 based board files can include this file and provide >> + * values for board specfic bindings. >> + * >> + * 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 <dt-bindings/clock/exynos7-clk.h> >> + >> +/ { >> + compatible = "samsung,exynos7"; >> + interrupt-parent = <&gic>; >> + #address-cells = <1>; >> + #size-cells = <1>; > > You should probably use address-cells/size-cells 2/2 on a 64-bit platform. > >> + aliases { >> + pinctrl0 = &pinctrl_0; >> + pinctrl1 = &pinctrl_1; >> + pinctrl2 = &pinctrl_2; >> + pinctrl3 = &pinctrl_3; >> + pinctrl4 = &pinctrl_4; >> + pinctrl5 = &pinctrl_5; >> + pinctrl6 = &pinctrl_6; >> + pinctrl7 = &pinctrl_7; >> + pinctrl8 = &pinctrl_8; >> + pinctrl9 = &pinctrl_9; >> + mshc0 = &mmc_0; >> + mshc2 = &mmc_2; >> + }; >> + >> + chipid at 10000000 { >> + compatible = "samsung,exynos4210-chipid"; >> + reg = <0x10000000 0x100>; >> + }; >> + >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; > > Why size-cells=2? Can you not fit a cpuid in 32 bits? > >> + cpu at 0 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a57", "arm,armv8"; >> + reg = <0x0 0x0>; >> + }; >> + }; >> + >> + fin_pll: xxti { >> + compatible = "fixed-clock"; >> + clock-frequency = <24000000>; >> + clock-output-names = "fin_pll"; >> + #clock-cells = <0>; >> + }; >> + >> + gic: interrupt-controller at 11001000 { >> + compatible = "arm,gic-400"; >> + #interrupt-cells = <3>; >> + #address-cells = <0>; >> + interrupt-controller; >> + reg = <0x11001000 0x1000>, >> + <0x11002000 0x1000>, >> + <0x11004000 0x2000>, >> + <0x11006000 0x2000>; >> + }; >> + >> + hsi2c_0: hsi2c at 13640000 { >> + compatible = "samsung,exynos7-hsi2c"; > > Is the i2c controller here completely new? > > Also, please use 'i2c' for node name on these nodes. > >> + reg = <0x13640000 0x1000>; >> + interrupts = <0 441 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&hs_i2c0_bus>; >> + clocks = <&clock_peric0 PCLK_HSI2C0>; >> + clock-names = "hsi2c"; >> + status = "disabled"; >> + }; >> + >> + hsi2c_1: hsi2c at 13650000 { >> + compatible = "samsung,exynos7-hsi2c"; >> + reg = <0x13650000 0x1000>; >> + interrupts = <0 442 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&hs_i2c1_bus>; >> + clocks = <&clock_peric0 PCLK_HSI2C1>; >> + clock-names = "hsi2c"; >> + status = "disabled"; >> + }; >> + >> + hsi2c_2: hsi2c at 14E60000 { > > I much prefer lowercase hex in unit addresses (and reg entries) below. I > know 32-bit uses uppercase, but let's switch going forward here. > >> + mct at 101C0000 { >> + compatible = "samsung,exynos4210-mct"; > > Please just do away with MCT here, and use architected timers going > forward. There really shouldn't be a need to keep supporting MCT any > more -- it's a construct from before arch timers on Cortex-A9. > >> + mmc_0: mmc at 15740000 { >> + compatible = "samsung,exynos7-dw-mshc-smu"; > > Is this controller backwards compatible with exynos5 ones? > >> + /* The Clock nodes are ordered as per the usermanual. */ > > "The clock" > > "user manual" > >> + timer { >> + compatible = "arm,armv8-timer"; >> + interrupts = <1 13 0xff01>, >> + <1 14 0xff01>, >> + <1 11 0xff01>, >> + <1 10 0xff01>; >> + clock-frequency = <24000000>; >> + use-clocksource-only; >> + use-physical-timer; > > These two properties are not standard, and I would expect any 64-bit > platform to come with PSCI such that you have a way to initialize the > virtual timers. It really sickens me that this is the n-th iteration of a Samsung SoC having the generic timer (basically since the 5250 came out), and still it is littered with stupid firmware bugs: - Broken CNTFRQ (as outlined by the need of clock-frequency) - Broken CNTVOFF (as hinted by the reliance on the physical timer) You would think that after over two years, someone would have a clue and added the missing 4 instructions to the boot ROM. Or not. M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 3:56 ` Olof Johansson @ 2014-08-28 9:48 ` Mark Rutland -1 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 9:48 UTC (permalink / raw) To: Olof Johansson Cc: Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Hi, > > + cpus { > > + #address-cells = <2>; > > + #size-cells = <0>; > > Why size-cells=2? Can you not fit a cpuid in 32 bits? As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing CPU reg property) Linux can handle single-cell cpu node reg entries where /cpus/#address-cells = <1>. I can't make any guarantees about other code (e.g. bootloaders) which might try to do things with cpu nodes, YMMV. [...] > > + hsi2c_2: hsi2c@14E60000 { > > I much prefer lowercase hex in unit addresses (and reg entries) below. I > know 32-bit uses uppercase, but let's switch going forward here. My preference also; I'm happy to enforce that on new dts. [...] > > + timer { > > + compatible = "arm,armv8-timer"; > > + interrupts = <1 13 0xff01>, > > + <1 14 0xff01>, > > + <1 11 0xff01>, > > + <1 10 0xff01>; > > + clock-frequency = <24000000>; > > + use-clocksource-only; > > + use-physical-timer; > > These two properties are not standard, and I would expect any 64-bit > platform to come with PSCI such that you have a way to initialize the > virtual timers. Likewise with clock-frequency. It's not a full workaround, and it's not hard to initialise CNTFRQ on each CPU. Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 9:48 ` Mark Rutland 0 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 9:48 UTC (permalink / raw) To: linux-arm-kernel Hi, > > + cpus { > > + #address-cells = <2>; > > + #size-cells = <0>; > > Why size-cells=2? Can you not fit a cpuid in 32 bits? As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing CPU reg property) Linux can handle single-cell cpu node reg entries where /cpus/#address-cells = <1>. I can't make any guarantees about other code (e.g. bootloaders) which might try to do things with cpu nodes, YMMV. [...] > > + hsi2c_2: hsi2c at 14E60000 { > > I much prefer lowercase hex in unit addresses (and reg entries) below. I > know 32-bit uses uppercase, but let's switch going forward here. My preference also; I'm happy to enforce that on new dts. [...] > > + timer { > > + compatible = "arm,armv8-timer"; > > + interrupts = <1 13 0xff01>, > > + <1 14 0xff01>, > > + <1 11 0xff01>, > > + <1 10 0xff01>; > > + clock-frequency = <24000000>; > > + use-clocksource-only; > > + use-physical-timer; > > These two properties are not standard, and I would expect any 64-bit > platform to come with PSCI such that you have a way to initialize the > virtual timers. Likewise with clock-frequency. It's not a full workaround, and it's not hard to initialise CNTFRQ on each CPU. Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 9:48 ` Mark Rutland @ 2014-08-28 16:28 ` Olof Johansson -1 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 16:28 UTC (permalink / raw) To: Mark Rutland Cc: Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: > Hi, > >> > + cpus { >> > + #address-cells = <2>; >> > + #size-cells = <0>; >> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? > > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing > CPU reg property) Linux can handle single-cell cpu node reg entries > where /cpus/#address-cells = <1>. > > I can't make any guarantees about other code (e.g. bootloaders) which > might try to do things with cpu nodes, YMMV. Ok. If address-cells is kept at 2 the unit address needs to be changed to "0,0". So one or the other has to be changed. > [...] > >> > + hsi2c_2: hsi2c@14E60000 { >> >> I much prefer lowercase hex in unit addresses (and reg entries) below. I >> know 32-bit uses uppercase, but let's switch going forward here. > > My preference also; I'm happy to enforce that on new dts. > > [...] > >> > + timer { >> > + compatible = "arm,armv8-timer"; >> > + interrupts = <1 13 0xff01>, >> > + <1 14 0xff01>, >> > + <1 11 0xff01>, >> > + <1 10 0xff01>; >> > + clock-frequency = <24000000>; >> > + use-clocksource-only; >> > + use-physical-timer; >> >> These two properties are not standard, and I would expect any 64-bit >> platform to come with PSCI such that you have a way to initialize the >> virtual timers. > > Likewise with clock-frequency. It's not a full workaround, and it's not > hard to initialise CNTFRQ on each CPU. Technically clock-frequency is documented, but not recommended to be used unless needed for working around firmware that doesn't setup the register value. :) In this case it's likely a cargo cult carry over from 5250 where the CNTFRQ requirement happened around the same time as we were working on it so that generation firmware lacked support for it -- it should since then have been fixed properly. -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 16:28 ` Olof Johansson 0 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 16:28 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: > Hi, > >> > + cpus { >> > + #address-cells = <2>; >> > + #size-cells = <0>; >> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? > > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing > CPU reg property) Linux can handle single-cell cpu node reg entries > where /cpus/#address-cells = <1>. > > I can't make any guarantees about other code (e.g. bootloaders) which > might try to do things with cpu nodes, YMMV. Ok. If address-cells is kept at 2 the unit address needs to be changed to "0,0". So one or the other has to be changed. > [...] > >> > + hsi2c_2: hsi2c at 14E60000 { >> >> I much prefer lowercase hex in unit addresses (and reg entries) below. I >> know 32-bit uses uppercase, but let's switch going forward here. > > My preference also; I'm happy to enforce that on new dts. > > [...] > >> > + timer { >> > + compatible = "arm,armv8-timer"; >> > + interrupts = <1 13 0xff01>, >> > + <1 14 0xff01>, >> > + <1 11 0xff01>, >> > + <1 10 0xff01>; >> > + clock-frequency = <24000000>; >> > + use-clocksource-only; >> > + use-physical-timer; >> >> These two properties are not standard, and I would expect any 64-bit >> platform to come with PSCI such that you have a way to initialize the >> virtual timers. > > Likewise with clock-frequency. It's not a full workaround, and it's not > hard to initialise CNTFRQ on each CPU. Technically clock-frequency is documented, but not recommended to be used unless needed for working around firmware that doesn't setup the register value. :) In this case it's likely a cargo cult carry over from 5250 where the CNTFRQ requirement happened around the same time as we were working on it so that generation firmware lacked support for it -- it should since then have been fixed properly. -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 16:28 ` Olof Johansson @ 2014-08-28 17:03 ` Mark Rutland -1 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 17:03 UTC (permalink / raw) To: Olof Johansson, marc.zyngier Cc: Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: > On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > Hi, > > > >> > + cpus { > >> > + #address-cells = <2>; > >> > + #size-cells = <0>; > >> > >> Why size-cells=2? Can you not fit a cpuid in 32 bits? > > > > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing > > CPU reg property) Linux can handle single-cell cpu node reg entries > > where /cpus/#address-cells = <1>. > > > > I can't make any guarantees about other code (e.g. bootloaders) which > > might try to do things with cpu nodes, YMMV. > > Ok. If address-cells is kept at 2 the unit address needs to be changed > to "0,0". So one or the other has to be changed. I'm happy either way. I'm not sure the rest of the tree had "0," prefixes on all of the unit-addresses for 64-bit addresses that were under 4GB, and I'm not sure that existing dts consistently do that either. Do we want to enforce that for all 64-bit unit-addresses? > > [...] > > > >> > + hsi2c_2: hsi2c@14E60000 { > >> > >> I much prefer lowercase hex in unit addresses (and reg entries) below. I > >> know 32-bit uses uppercase, but let's switch going forward here. > > > > My preference also; I'm happy to enforce that on new dts. > > > > [...] > > > >> > + timer { > >> > + compatible = "arm,armv8-timer"; > >> > + interrupts = <1 13 0xff01>, > >> > + <1 14 0xff01>, > >> > + <1 11 0xff01>, > >> > + <1 10 0xff01>; > >> > + clock-frequency = <24000000>; > >> > + use-clocksource-only; > >> > + use-physical-timer; > >> > >> These two properties are not standard, and I would expect any 64-bit > >> platform to come with PSCI such that you have a way to initialize the > >> virtual timers. > > > > Likewise with clock-frequency. It's not a full workaround, and it's not > > hard to initialise CNTFRQ on each CPU. > > Technically clock-frequency is documented, but not recommended to be > used unless needed for working around firmware that doesn't setup the > register value. :) True. > In this case it's likely a cargo cult carry over from 5250 where the > CNTFRQ requirement happened around the same time as we were working on > it so that generation firmware lacked support for it -- it should > since then have been fixed properly. It's probably unhelpful that the documentation isn't explicit about that. On that front, how about the patch below? Mark. ---->8---- >From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 From: Mark Rutland <mark.rutland@arm.com> Date: Thu, 28 Aug 2014 17:41:03 +0100 Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use The ARM Generic Timer (AKA the architected timer, arm_arch_timer) features a CPU register (CNTFRQ) which firmware is intended to initialize, and non-secure software can read to determine the frequency of the timer. On CPUs with secure state, this register cannot be written from non-secure states. The firmware of early SoCs featuring the timer did not correctly initialize CNTFRQ correctly on all CPUs, requiring the frequency to be described in DT as a workaround. This workaround is not complete however as CNTFRQ is exposed to all software in a privileged non-secure mode, including KVM guests. The firmware and DTs for recent SoCs have followed the example set by these early SoCs. This patch updates the arch timer binding documentation to make it clearer that the use of the clock-frequency property is a poor work-around. The MMIO generic timer binding is similarly updated, though this is less of a concern as there is generally no need to expose the MMIO timers to guest OSs. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> --- Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt index 37b2caf..5ca3f95 100644 --- a/Documentation/devicetree/bindings/arm/arch_timer.txt +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. - interrupts : Interrupt list for secure, non-secure, virtual and hypervisor timers, in that order. -- clock-frequency : The frequency of the main counter, in Hz. Optional. +- clock-frequency : The frequency of the main counter, in Hz. Should be present + only where necessary to work around BROKEN firmware which does not configure + CNTFRQ on all CPUs to a uniform correct value. Use of this property is + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. - always-on : a boolean property. If present, the timer is powered through an always-on power domain, therefore it never loses context. @@ -38,7 +41,8 @@ Example: - compatible : Should at least contain "arm,armv7-timer-mem". -- clock-frequency : The frequency of the main counter, in Hz. Optional. +- clock-frequency : The frequency of the main counter, in Hz. Should be present + only when firmware has not configured the MMIO CNTFRQ registers. - reg : The control frame base address. -- 1.9.1 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:03 ` Mark Rutland 0 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 17:03 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: > On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > Hi, > > > >> > + cpus { > >> > + #address-cells = <2>; > >> > + #size-cells = <0>; > >> > >> Why size-cells=2? Can you not fit a cpuid in 32 bits? > > > > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing > > CPU reg property) Linux can handle single-cell cpu node reg entries > > where /cpus/#address-cells = <1>. > > > > I can't make any guarantees about other code (e.g. bootloaders) which > > might try to do things with cpu nodes, YMMV. > > Ok. If address-cells is kept at 2 the unit address needs to be changed > to "0,0". So one or the other has to be changed. I'm happy either way. I'm not sure the rest of the tree had "0," prefixes on all of the unit-addresses for 64-bit addresses that were under 4GB, and I'm not sure that existing dts consistently do that either. Do we want to enforce that for all 64-bit unit-addresses? > > [...] > > > >> > + hsi2c_2: hsi2c at 14E60000 { > >> > >> I much prefer lowercase hex in unit addresses (and reg entries) below. I > >> know 32-bit uses uppercase, but let's switch going forward here. > > > > My preference also; I'm happy to enforce that on new dts. > > > > [...] > > > >> > + timer { > >> > + compatible = "arm,armv8-timer"; > >> > + interrupts = <1 13 0xff01>, > >> > + <1 14 0xff01>, > >> > + <1 11 0xff01>, > >> > + <1 10 0xff01>; > >> > + clock-frequency = <24000000>; > >> > + use-clocksource-only; > >> > + use-physical-timer; > >> > >> These two properties are not standard, and I would expect any 64-bit > >> platform to come with PSCI such that you have a way to initialize the > >> virtual timers. > > > > Likewise with clock-frequency. It's not a full workaround, and it's not > > hard to initialise CNTFRQ on each CPU. > > Technically clock-frequency is documented, but not recommended to be > used unless needed for working around firmware that doesn't setup the > register value. :) True. > In this case it's likely a cargo cult carry over from 5250 where the > CNTFRQ requirement happened around the same time as we were working on > it so that generation firmware lacked support for it -- it should > since then have been fixed properly. It's probably unhelpful that the documentation isn't explicit about that. On that front, how about the patch below? Mark. ---->8---- >From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 From: Mark Rutland <mark.rutland@arm.com> Date: Thu, 28 Aug 2014 17:41:03 +0100 Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use The ARM Generic Timer (AKA the architected timer, arm_arch_timer) features a CPU register (CNTFRQ) which firmware is intended to initialize, and non-secure software can read to determine the frequency of the timer. On CPUs with secure state, this register cannot be written from non-secure states. The firmware of early SoCs featuring the timer did not correctly initialize CNTFRQ correctly on all CPUs, requiring the frequency to be described in DT as a workaround. This workaround is not complete however as CNTFRQ is exposed to all software in a privileged non-secure mode, including KVM guests. The firmware and DTs for recent SoCs have followed the example set by these early SoCs. This patch updates the arch timer binding documentation to make it clearer that the use of the clock-frequency property is a poor work-around. The MMIO generic timer binding is similarly updated, though this is less of a concern as there is generally no need to expose the MMIO timers to guest OSs. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> --- Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt index 37b2caf..5ca3f95 100644 --- a/Documentation/devicetree/bindings/arm/arch_timer.txt +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. - interrupts : Interrupt list for secure, non-secure, virtual and hypervisor timers, in that order. -- clock-frequency : The frequency of the main counter, in Hz. Optional. +- clock-frequency : The frequency of the main counter, in Hz. Should be present + only where necessary to work around BROKEN firmware which does not configure + CNTFRQ on all CPUs to a uniform correct value. Use of this property is + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. - always-on : a boolean property. If present, the timer is powered through an always-on power domain, therefore it never loses context. @@ -38,7 +41,8 @@ Example: - compatible : Should at least contain "arm,armv7-timer-mem". -- clock-frequency : The frequency of the main counter, in Hz. Optional. +- clock-frequency : The frequency of the main counter, in Hz. Should be present + only when firmware has not configured the MMIO CNTFRQ registers. - reg : The control frame base address. -- 1.9.1 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:03 ` Mark Rutland @ 2014-08-28 17:19 ` Olof Johansson -1 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 17:19 UTC (permalink / raw) To: Mark Rutland Cc: Marc Zyngier, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@arm.com> wrote: > On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: >> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> > Hi, >> > >> >> > + cpus { >> >> > + #address-cells = <2>; >> >> > + #size-cells = <0>; >> >> >> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? >> > >> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing >> > CPU reg property) Linux can handle single-cell cpu node reg entries >> > where /cpus/#address-cells = <1>. >> > >> > I can't make any guarantees about other code (e.g. bootloaders) which >> > might try to do things with cpu nodes, YMMV. >> >> Ok. If address-cells is kept at 2 the unit address needs to be changed >> to "0,0". So one or the other has to be changed. > > I'm happy either way. > > I'm not sure the rest of the tree had "0," prefixes on all of the > unit-addresses for 64-bit addresses that were under 4GB, and I'm not > sure that existing dts consistently do that either. > > Do we want to enforce that for all 64-bit unit-addresses? Yeah, I believe that's the only valid format for a 2-address-cell unit address. >> > [...] >> > >> >> > + hsi2c_2: hsi2c@14E60000 { >> >> >> >> I much prefer lowercase hex in unit addresses (and reg entries) below. I >> >> know 32-bit uses uppercase, but let's switch going forward here. >> > >> > My preference also; I'm happy to enforce that on new dts. >> > >> > [...] >> > >> >> > + timer { >> >> > + compatible = "arm,armv8-timer"; >> >> > + interrupts = <1 13 0xff01>, >> >> > + <1 14 0xff01>, >> >> > + <1 11 0xff01>, >> >> > + <1 10 0xff01>; >> >> > + clock-frequency = <24000000>; >> >> > + use-clocksource-only; >> >> > + use-physical-timer; >> >> >> >> These two properties are not standard, and I would expect any 64-bit >> >> platform to come with PSCI such that you have a way to initialize the >> >> virtual timers. >> > >> > Likewise with clock-frequency. It's not a full workaround, and it's not >> > hard to initialise CNTFRQ on each CPU. >> >> Technically clock-frequency is documented, but not recommended to be >> used unless needed for working around firmware that doesn't setup the >> register value. :) > > True. > >> In this case it's likely a cargo cult carry over from 5250 where the >> CNTFRQ requirement happened around the same time as we were working on >> it so that generation firmware lacked support for it -- it should >> since then have been fixed properly. > > It's probably unhelpful that the documentation isn't explicit about > that. On that front, how about the patch below? > > Mark. > > ---->8---- > From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > From: Mark Rutland <mark.rutland@arm.com> > Date: Thu, 28 Aug 2014 17:41:03 +0100 > Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > > The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > features a CPU register (CNTFRQ) which firmware is intended to > initialize, and non-secure software can read to determine the frequency > of the timer. On CPUs with secure state, this register cannot be written > from non-secure states. > > The firmware of early SoCs featuring the timer did not correctly > initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > described in DT as a workaround. This workaround is not complete however > as CNTFRQ is exposed to all software in a privileged non-secure mode, > including KVM guests. The firmware and DTs for recent SoCs have followed > the example set by these early SoCs. > > This patch updates the arch timer binding documentation to make it > clearer that the use of the clock-frequency property is a poor > work-around. The MMIO generic timer binding is similarly updated, though > this is less of a concern as there is generally no need to expose the > MMIO timers to guest OSs. > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > Cc: Marc Zyngier <marc.zyngier@arm.com> With caps fixed: Acked-by: Olof Johansson <olof@lixom.net> > --- > Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt > index 37b2caf..5ca3f95 100644 > --- a/Documentation/devicetree/bindings/arm/arch_timer.txt > +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt > @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. > - interrupts : Interrupt list for secure, non-secure, virtual and > hypervisor timers, in that order. > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > + only where necessary to work around BROKEN firmware which does not configure No need to do broken in all caps. In reality I don't expect it to make a difference on people complying or not. :) > + CNTFRQ on all CPUs to a uniform correct value. Use of this property is > + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. Same here. > > - always-on : a boolean property. If present, the timer is powered through an > always-on power domain, therefore it never loses context. > @@ -38,7 +41,8 @@ Example: > > - compatible : Should at least contain "arm,armv7-timer-mem". > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > + only when firmware has not configured the MMIO CNTFRQ registers. > > - reg : The control frame base address. > > -- > 1.9.1 > ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:19 ` Olof Johansson 0 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 17:19 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@arm.com> wrote: > On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: >> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> > Hi, >> > >> >> > + cpus { >> >> > + #address-cells = <2>; >> >> > + #size-cells = <0>; >> >> >> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? >> > >> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing >> > CPU reg property) Linux can handle single-cell cpu node reg entries >> > where /cpus/#address-cells = <1>. >> > >> > I can't make any guarantees about other code (e.g. bootloaders) which >> > might try to do things with cpu nodes, YMMV. >> >> Ok. If address-cells is kept at 2 the unit address needs to be changed >> to "0,0". So one or the other has to be changed. > > I'm happy either way. > > I'm not sure the rest of the tree had "0," prefixes on all of the > unit-addresses for 64-bit addresses that were under 4GB, and I'm not > sure that existing dts consistently do that either. > > Do we want to enforce that for all 64-bit unit-addresses? Yeah, I believe that's the only valid format for a 2-address-cell unit address. >> > [...] >> > >> >> > + hsi2c_2: hsi2c at 14E60000 { >> >> >> >> I much prefer lowercase hex in unit addresses (and reg entries) below. I >> >> know 32-bit uses uppercase, but let's switch going forward here. >> > >> > My preference also; I'm happy to enforce that on new dts. >> > >> > [...] >> > >> >> > + timer { >> >> > + compatible = "arm,armv8-timer"; >> >> > + interrupts = <1 13 0xff01>, >> >> > + <1 14 0xff01>, >> >> > + <1 11 0xff01>, >> >> > + <1 10 0xff01>; >> >> > + clock-frequency = <24000000>; >> >> > + use-clocksource-only; >> >> > + use-physical-timer; >> >> >> >> These two properties are not standard, and I would expect any 64-bit >> >> platform to come with PSCI such that you have a way to initialize the >> >> virtual timers. >> > >> > Likewise with clock-frequency. It's not a full workaround, and it's not >> > hard to initialise CNTFRQ on each CPU. >> >> Technically clock-frequency is documented, but not recommended to be >> used unless needed for working around firmware that doesn't setup the >> register value. :) > > True. > >> In this case it's likely a cargo cult carry over from 5250 where the >> CNTFRQ requirement happened around the same time as we were working on >> it so that generation firmware lacked support for it -- it should >> since then have been fixed properly. > > It's probably unhelpful that the documentation isn't explicit about > that. On that front, how about the patch below? > > Mark. > > ---->8---- > From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > From: Mark Rutland <mark.rutland@arm.com> > Date: Thu, 28 Aug 2014 17:41:03 +0100 > Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > > The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > features a CPU register (CNTFRQ) which firmware is intended to > initialize, and non-secure software can read to determine the frequency > of the timer. On CPUs with secure state, this register cannot be written > from non-secure states. > > The firmware of early SoCs featuring the timer did not correctly > initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > described in DT as a workaround. This workaround is not complete however > as CNTFRQ is exposed to all software in a privileged non-secure mode, > including KVM guests. The firmware and DTs for recent SoCs have followed > the example set by these early SoCs. > > This patch updates the arch timer binding documentation to make it > clearer that the use of the clock-frequency property is a poor > work-around. The MMIO generic timer binding is similarly updated, though > this is less of a concern as there is generally no need to expose the > MMIO timers to guest OSs. > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > Cc: Marc Zyngier <marc.zyngier@arm.com> With caps fixed: Acked-by: Olof Johansson <olof@lixom.net> > --- > Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt > index 37b2caf..5ca3f95 100644 > --- a/Documentation/devicetree/bindings/arm/arch_timer.txt > +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt > @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. > - interrupts : Interrupt list for secure, non-secure, virtual and > hypervisor timers, in that order. > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > + only where necessary to work around BROKEN firmware which does not configure No need to do broken in all caps. In reality I don't expect it to make a difference on people complying or not. :) > + CNTFRQ on all CPUs to a uniform correct value. Use of this property is > + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. Same here. > > - always-on : a boolean property. If present, the timer is powered through an > always-on power domain, therefore it never loses context. > @@ -38,7 +41,8 @@ Example: > > - compatible : Should at least contain "arm,armv7-timer-mem". > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > + only when firmware has not configured the MMIO CNTFRQ registers. > > - reg : The control frame base address. > > -- > 1.9.1 > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:19 ` Olof Johansson @ 2014-08-28 17:39 ` Mark Rutland -1 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 17:39 UTC (permalink / raw) To: Olof Johansson Cc: Marc Zyngier, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring On Thu, Aug 28, 2014 at 06:19:00PM +0100, Olof Johansson wrote: > On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: > >> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >> > Hi, > >> > > >> >> > + cpus { > >> >> > + #address-cells = <2>; > >> >> > + #size-cells = <0>; > >> >> > >> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? > >> > > >> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing > >> > CPU reg property) Linux can handle single-cell cpu node reg entries > >> > where /cpus/#address-cells = <1>. > >> > > >> > I can't make any guarantees about other code (e.g. bootloaders) which > >> > might try to do things with cpu nodes, YMMV. > >> > >> Ok. If address-cells is kept at 2 the unit address needs to be changed > >> to "0,0". So one or the other has to be changed. > > > > I'm happy either way. > > > > I'm not sure the rest of the tree had "0," prefixes on all of the > > unit-addresses for 64-bit addresses that were under 4GB, and I'm not > > sure that existing dts consistently do that either. > > > > Do we want to enforce that for all 64-bit unit-addresses? > > Yeah, I believe that's the only valid format for a 2-address-cell unit address. Fair enough. I didn't spot this explicitly mentioned anywhere in ePAPR, but the examples match. I should probably re-jig that checkpatch test I had for unit-addresses. > >> > [...] > >> > > >> >> > + hsi2c_2: hsi2c@14E60000 { > >> >> > >> >> I much prefer lowercase hex in unit addresses (and reg entries) below. I > >> >> know 32-bit uses uppercase, but let's switch going forward here. > >> > > >> > My preference also; I'm happy to enforce that on new dts. > >> > > >> > [...] > >> > > >> >> > + timer { > >> >> > + compatible = "arm,armv8-timer"; > >> >> > + interrupts = <1 13 0xff01>, > >> >> > + <1 14 0xff01>, > >> >> > + <1 11 0xff01>, > >> >> > + <1 10 0xff01>; > >> >> > + clock-frequency = <24000000>; > >> >> > + use-clocksource-only; > >> >> > + use-physical-timer; > >> >> > >> >> These two properties are not standard, and I would expect any 64-bit > >> >> platform to come with PSCI such that you have a way to initialize the > >> >> virtual timers. > >> > > >> > Likewise with clock-frequency. It's not a full workaround, and it's not > >> > hard to initialise CNTFRQ on each CPU. > >> > >> Technically clock-frequency is documented, but not recommended to be > >> used unless needed for working around firmware that doesn't setup the > >> register value. :) > > > > True. > > > >> In this case it's likely a cargo cult carry over from 5250 where the > >> CNTFRQ requirement happened around the same time as we were working on > >> it so that generation firmware lacked support for it -- it should > >> since then have been fixed properly. > > > > It's probably unhelpful that the documentation isn't explicit about > > that. On that front, how about the patch below? > > > > Mark. > > > > ---->8---- > > From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > > From: Mark Rutland <mark.rutland@arm.com> > > Date: Thu, 28 Aug 2014 17:41:03 +0100 > > Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > > > > The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > > features a CPU register (CNTFRQ) which firmware is intended to > > initialize, and non-secure software can read to determine the frequency > > of the timer. On CPUs with secure state, this register cannot be written > > from non-secure states. > > > > The firmware of early SoCs featuring the timer did not correctly > > initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > > described in DT as a workaround. This workaround is not complete however > > as CNTFRQ is exposed to all software in a privileged non-secure mode, > > including KVM guests. The firmware and DTs for recent SoCs have followed > > the example set by these early SoCs. > > > > This patch updates the arch timer binding documentation to make it > > clearer that the use of the clock-frequency property is a poor > > work-around. The MMIO generic timer binding is similarly updated, though > > this is less of a concern as there is generally no need to expose the > > MMIO timers to guest OSs. > > > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > > Cc: Marc Zyngier <marc.zyngier@arm.com> > > With caps fixed: > > Acked-by: Olof Johansson <olof@lixom.net> Cheers. > > --- > > Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt > > index 37b2caf..5ca3f95 100644 > > --- a/Documentation/devicetree/bindings/arm/arch_timer.txt > > +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt > > @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. > > - interrupts : Interrupt list for secure, non-secure, virtual and > > hypervisor timers, in that order. > > > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > > + only where necessary to work around BROKEN firmware which does not configure > > No need to do broken in all caps. In reality I don't expect it to make > a difference on people complying or not. :) Sure. I'll save the caps for replies to violators ;) Mark. > > + CNTFRQ on all CPUs to a uniform correct value. Use of this property is > > + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. > > Same here. > > > > > - always-on : a boolean property. If present, the timer is powered through an > > always-on power domain, therefore it never loses context. > > @@ -38,7 +41,8 @@ Example: > > > > - compatible : Should at least contain "arm,armv7-timer-mem". > > > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > > + only when firmware has not configured the MMIO CNTFRQ registers. > > > > - reg : The control frame base address. > > > > -- > > 1.9.1 > > > ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:39 ` Mark Rutland 0 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 17:39 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 06:19:00PM +0100, Olof Johansson wrote: > On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: > >> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >> > Hi, > >> > > >> >> > + cpus { > >> >> > + #address-cells = <2>; > >> >> > + #size-cells = <0>; > >> >> > >> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? > >> > > >> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing > >> > CPU reg property) Linux can handle single-cell cpu node reg entries > >> > where /cpus/#address-cells = <1>. > >> > > >> > I can't make any guarantees about other code (e.g. bootloaders) which > >> > might try to do things with cpu nodes, YMMV. > >> > >> Ok. If address-cells is kept at 2 the unit address needs to be changed > >> to "0,0". So one or the other has to be changed. > > > > I'm happy either way. > > > > I'm not sure the rest of the tree had "0," prefixes on all of the > > unit-addresses for 64-bit addresses that were under 4GB, and I'm not > > sure that existing dts consistently do that either. > > > > Do we want to enforce that for all 64-bit unit-addresses? > > Yeah, I believe that's the only valid format for a 2-address-cell unit address. Fair enough. I didn't spot this explicitly mentioned anywhere in ePAPR, but the examples match. I should probably re-jig that checkpatch test I had for unit-addresses. > >> > [...] > >> > > >> >> > + hsi2c_2: hsi2c at 14E60000 { > >> >> > >> >> I much prefer lowercase hex in unit addresses (and reg entries) below. I > >> >> know 32-bit uses uppercase, but let's switch going forward here. > >> > > >> > My preference also; I'm happy to enforce that on new dts. > >> > > >> > [...] > >> > > >> >> > + timer { > >> >> > + compatible = "arm,armv8-timer"; > >> >> > + interrupts = <1 13 0xff01>, > >> >> > + <1 14 0xff01>, > >> >> > + <1 11 0xff01>, > >> >> > + <1 10 0xff01>; > >> >> > + clock-frequency = <24000000>; > >> >> > + use-clocksource-only; > >> >> > + use-physical-timer; > >> >> > >> >> These two properties are not standard, and I would expect any 64-bit > >> >> platform to come with PSCI such that you have a way to initialize the > >> >> virtual timers. > >> > > >> > Likewise with clock-frequency. It's not a full workaround, and it's not > >> > hard to initialise CNTFRQ on each CPU. > >> > >> Technically clock-frequency is documented, but not recommended to be > >> used unless needed for working around firmware that doesn't setup the > >> register value. :) > > > > True. > > > >> In this case it's likely a cargo cult carry over from 5250 where the > >> CNTFRQ requirement happened around the same time as we were working on > >> it so that generation firmware lacked support for it -- it should > >> since then have been fixed properly. > > > > It's probably unhelpful that the documentation isn't explicit about > > that. On that front, how about the patch below? > > > > Mark. > > > > ---->8---- > > From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > > From: Mark Rutland <mark.rutland@arm.com> > > Date: Thu, 28 Aug 2014 17:41:03 +0100 > > Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > > > > The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > > features a CPU register (CNTFRQ) which firmware is intended to > > initialize, and non-secure software can read to determine the frequency > > of the timer. On CPUs with secure state, this register cannot be written > > from non-secure states. > > > > The firmware of early SoCs featuring the timer did not correctly > > initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > > described in DT as a workaround. This workaround is not complete however > > as CNTFRQ is exposed to all software in a privileged non-secure mode, > > including KVM guests. The firmware and DTs for recent SoCs have followed > > the example set by these early SoCs. > > > > This patch updates the arch timer binding documentation to make it > > clearer that the use of the clock-frequency property is a poor > > work-around. The MMIO generic timer binding is similarly updated, though > > this is less of a concern as there is generally no need to expose the > > MMIO timers to guest OSs. > > > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > > Cc: Marc Zyngier <marc.zyngier@arm.com> > > With caps fixed: > > Acked-by: Olof Johansson <olof@lixom.net> Cheers. > > --- > > Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt > > index 37b2caf..5ca3f95 100644 > > --- a/Documentation/devicetree/bindings/arm/arch_timer.txt > > +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt > > @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. > > - interrupts : Interrupt list for secure, non-secure, virtual and > > hypervisor timers, in that order. > > > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > > + only where necessary to work around BROKEN firmware which does not configure > > No need to do broken in all caps. In reality I don't expect it to make > a difference on people complying or not. :) Sure. I'll save the caps for replies to violators ;) Mark. > > + CNTFRQ on all CPUs to a uniform correct value. Use of this property is > > + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. > > Same here. > > > > > - always-on : a boolean property. If present, the timer is powered through an > > always-on power domain, therefore it never loses context. > > @@ -38,7 +41,8 @@ Example: > > > > - compatible : Should at least contain "arm,armv7-timer-mem". > > > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > > + only when firmware has not configured the MMIO CNTFRQ registers. > > > > - reg : The control frame base address. > > > > -- > > 1.9.1 > > > ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:39 ` Mark Rutland @ 2014-08-28 17:47 ` Geert Uytterhoeven -1 siblings, 0 replies; 84+ messages in thread From: Geert Uytterhoeven @ 2014-08-28 17:47 UTC (permalink / raw) To: Mark Rutland Cc: Olof Johansson, devicetree, linux-samsung-soc, Rob Herring, Marc Zyngier, Catalin Marinas, Thomas Abraham, cpgs, naveenkrishna.ch, Naveen Krishna Chatradhi, linux-arm-kernel Hi Mark, On Thu, Aug 28, 2014 at 7:39 PM, Mark Rutland <mark.rutland@arm.com> wrote: >> >> Ok. If address-cells is kept at 2 the unit address needs to be changed >> >> to "0,0". So one or the other has to be changed. >> > >> > I'm happy either way. >> > >> > I'm not sure the rest of the tree had "0," prefixes on all of the >> > unit-addresses for 64-bit addresses that were under 4GB, and I'm not >> > sure that existing dts consistently do that either. >> > >> > Do we want to enforce that for all 64-bit unit-addresses? >> >> Yeah, I believe that's the only valid format for a 2-address-cell unit address. > > Fair enough. I didn't spot this explicitly mentioned anywhere in ePAPR, > but the examples match. I couldn't find much about how the unit-addresses should really look like. Power_ePAPR_APPROVED_v1.1.pdf: "The unit-address component of the name is specific to the bus type on which the node sits. It consists of one or more ASCII characters from the set of characters in Table 2-1. The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @ and unit-address must be omitted and the node-name alone differentiates the node from other nodes at the same level in the tree. The binding for a particular bus may specify additional, more specific requirements for the format of reg and the unit-address." "Table 2.1" contains lot of characters, definitely not limited to hex numbers. Also nothing about (not) needing a "0x" prefix. > I should probably re-jig that checkpatch test I had for unit-addresses. It would be great if dtc started complaining about unit-addresses not matching the first reg property. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:47 ` Geert Uytterhoeven 0 siblings, 0 replies; 84+ messages in thread From: Geert Uytterhoeven @ 2014-08-28 17:47 UTC (permalink / raw) To: linux-arm-kernel Hi Mark, On Thu, Aug 28, 2014 at 7:39 PM, Mark Rutland <mark.rutland@arm.com> wrote: >> >> Ok. If address-cells is kept at 2 the unit address needs to be changed >> >> to "0,0". So one or the other has to be changed. >> > >> > I'm happy either way. >> > >> > I'm not sure the rest of the tree had "0," prefixes on all of the >> > unit-addresses for 64-bit addresses that were under 4GB, and I'm not >> > sure that existing dts consistently do that either. >> > >> > Do we want to enforce that for all 64-bit unit-addresses? >> >> Yeah, I believe that's the only valid format for a 2-address-cell unit address. > > Fair enough. I didn't spot this explicitly mentioned anywhere in ePAPR, > but the examples match. I couldn't find much about how the unit-addresses should really look like. Power_ePAPR_APPROVED_v1.1.pdf: "The unit-address component of the name is specific to the bus type on which the node sits. It consists of one or more ASCII characters from the set of characters in Table 2-1. The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @ and unit-address must be omitted and the node-name alone differentiates the node from other nodes at the same level in the tree. The binding for a particular bus may specify additional, more specific requirements for the format of reg and the unit-address." "Table 2.1" contains lot of characters, definitely not limited to hex numbers. Also nothing about (not) needing a "0x" prefix. > I should probably re-jig that checkpatch test I had for unit-addresses. It would be great if dtc started complaining about unit-addresses not matching the first reg property. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:47 ` Geert Uytterhoeven @ 2014-08-28 18:17 ` Mark Rutland -1 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 18:17 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Olof Johansson, devicetree, linux-samsung-soc, Rob Herring, Marc Zyngier, Catalin Marinas, Thomas Abraham, cpgs, naveenkrishna.ch, Naveen Krishna Chatradhi, linux-arm-kernel On Thu, Aug 28, 2014 at 06:47:00PM +0100, Geert Uytterhoeven wrote: > Hi Mark, > > On Thu, Aug 28, 2014 at 7:39 PM, Mark Rutland <mark.rutland@arm.com> wrote: > >> >> Ok. If address-cells is kept at 2 the unit address needs to be changed > >> >> to "0,0". So one or the other has to be changed. > >> > > >> > I'm happy either way. > >> > > >> > I'm not sure the rest of the tree had "0," prefixes on all of the > >> > unit-addresses for 64-bit addresses that were under 4GB, and I'm not > >> > sure that existing dts consistently do that either. > >> > > >> > Do we want to enforce that for all 64-bit unit-addresses? > >> > >> Yeah, I believe that's the only valid format for a 2-address-cell unit address. > > > > Fair enough. I didn't spot this explicitly mentioned anywhere in ePAPR, > > but the examples match. > > I couldn't find much about how the unit-addresses should really look like. > > Power_ePAPR_APPROVED_v1.1.pdf: > "The unit-address component of the name is specific to the bus type on > which the node sits. It consists > of one or more ASCII characters from the set of characters in Table > 2-1. The unit-address must > match the first address specified in the reg property of the node. If > the node has no reg property, the > @ and unit-address must be omitted and the node-name alone > differentiates the node from other nodes > at the same level in the tree. The binding for a particular bus may > specify additional, more specific > requirements for the format of reg and the unit-address." > > "Table 2.1" contains lot of characters, definitely not limited to hex numbers. > Also nothing about (not) needing a "0x" prefix. This is unfortunate. I guess this was assumed to be implied by way of the examples. :/ > > I should probably re-jig that checkpatch test I had for unit-addresses. > > It would be great if dtc started complaining about unit-addresses not > matching the first reg property. Agreed. When I last tried I thought that required more complex parsing than could be done with a regex. That said, I'd forgotten that properties must come before child nodes, so I though I had to at least balance '{' and '}' for children. I guess all we need to do is find a line beginning with '\s*reg\s*=\s*<' before the next '{' or '}'. Maybe this will be easier than previously thought. :) Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 18:17 ` Mark Rutland 0 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 18:17 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 06:47:00PM +0100, Geert Uytterhoeven wrote: > Hi Mark, > > On Thu, Aug 28, 2014 at 7:39 PM, Mark Rutland <mark.rutland@arm.com> wrote: > >> >> Ok. If address-cells is kept at 2 the unit address needs to be changed > >> >> to "0,0". So one or the other has to be changed. > >> > > >> > I'm happy either way. > >> > > >> > I'm not sure the rest of the tree had "0," prefixes on all of the > >> > unit-addresses for 64-bit addresses that were under 4GB, and I'm not > >> > sure that existing dts consistently do that either. > >> > > >> > Do we want to enforce that for all 64-bit unit-addresses? > >> > >> Yeah, I believe that's the only valid format for a 2-address-cell unit address. > > > > Fair enough. I didn't spot this explicitly mentioned anywhere in ePAPR, > > but the examples match. > > I couldn't find much about how the unit-addresses should really look like. > > Power_ePAPR_APPROVED_v1.1.pdf: > "The unit-address component of the name is specific to the bus type on > which the node sits. It consists > of one or more ASCII characters from the set of characters in Table > 2-1. The unit-address must > match the first address specified in the reg property of the node. If > the node has no reg property, the > @ and unit-address must be omitted and the node-name alone > differentiates the node from other nodes > at the same level in the tree. The binding for a particular bus may > specify additional, more specific > requirements for the format of reg and the unit-address." > > "Table 2.1" contains lot of characters, definitely not limited to hex numbers. > Also nothing about (not) needing a "0x" prefix. This is unfortunate. I guess this was assumed to be implied by way of the examples. :/ > > I should probably re-jig that checkpatch test I had for unit-addresses. > > It would be great if dtc started complaining about unit-addresses not > matching the first reg property. Agreed. When I last tried I thought that required more complex parsing than could be done with a regex. That said, I'd forgotten that properties must come before child nodes, so I though I had to at least balance '{' and '}' for children. I guess all we need to do is find a line beginning with '\s*reg\s*=\s*<' before the next '{' or '}'. Maybe this will be easier than previously thought. :) Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:19 ` Olof Johansson @ 2014-08-28 17:54 ` Rob Herring -1 siblings, 0 replies; 84+ messages in thread From: Rob Herring @ 2014-08-28 17:54 UTC (permalink / raw) To: Olof Johansson Cc: Mark Rutland, Marc Zyngier, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham On Thu, Aug 28, 2014 at 12:19 PM, Olof Johansson <olof@lixom.net> wrote: > On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: >>> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: >>> > Hi, >>> > >>> >> > + cpus { >>> >> > + #address-cells = <2>; >>> >> > + #size-cells = <0>; >>> >> >>> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? >>> > >>> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing >>> > CPU reg property) Linux can handle single-cell cpu node reg entries >>> > where /cpus/#address-cells = <1>. >>> > >>> > I can't make any guarantees about other code (e.g. bootloaders) which >>> > might try to do things with cpu nodes, YMMV. >>> >>> Ok. If address-cells is kept at 2 the unit address needs to be changed >>> to "0,0". So one or the other has to be changed. >> >> I'm happy either way. >> >> I'm not sure the rest of the tree had "0," prefixes on all of the >> unit-addresses for 64-bit addresses that were under 4GB, and I'm not >> sure that existing dts consistently do that either. >> >> Do we want to enforce that for all 64-bit unit-addresses? > > Yeah, I believe that's the only valid format for a 2-address-cell unit address. But we don't do leading 0's anywhere else like single cell unit addresses. Buses expressed with ranges and offsets are one example. Also, I2C addresses have a 32-bit size in DT yet are only 8-bit and we don't do leading zero's there. Rob ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:54 ` Rob Herring 0 siblings, 0 replies; 84+ messages in thread From: Rob Herring @ 2014-08-28 17:54 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 12:19 PM, Olof Johansson <olof@lixom.net> wrote: > On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: >>> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: >>> > Hi, >>> > >>> >> > + cpus { >>> >> > + #address-cells = <2>; >>> >> > + #size-cells = <0>; >>> >> >>> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? >>> > >>> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing >>> > CPU reg property) Linux can handle single-cell cpu node reg entries >>> > where /cpus/#address-cells = <1>. >>> > >>> > I can't make any guarantees about other code (e.g. bootloaders) which >>> > might try to do things with cpu nodes, YMMV. >>> >>> Ok. If address-cells is kept at 2 the unit address needs to be changed >>> to "0,0". So one or the other has to be changed. >> >> I'm happy either way. >> >> I'm not sure the rest of the tree had "0," prefixes on all of the >> unit-addresses for 64-bit addresses that were under 4GB, and I'm not >> sure that existing dts consistently do that either. >> >> Do we want to enforce that for all 64-bit unit-addresses? > > Yeah, I believe that's the only valid format for a 2-address-cell unit address. But we don't do leading 0's anywhere else like single cell unit addresses. Buses expressed with ranges and offsets are one example. Also, I2C addresses have a 32-bit size in DT yet are only 8-bit and we don't do leading zero's there. Rob ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:54 ` Rob Herring @ 2014-08-28 22:23 ` Olof Johansson -1 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 22:23 UTC (permalink / raw) To: Rob Herring Cc: Mark Rutland, Marc Zyngier, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Benjamin Herrenschmidt, Simon Horman On Thu, Aug 28, 2014 at 10:54 AM, Rob Herring <robh@kernel.org> wrote: > On Thu, Aug 28, 2014 at 12:19 PM, Olof Johansson <olof@lixom.net> wrote: >> On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@arm.com> wrote: >>> On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: >>>> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: >>>> > Hi, >>>> > >>>> >> > + cpus { >>>> >> > + #address-cells = <2>; >>>> >> > + #size-cells = <0>; >>>> >> >>>> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? >>>> > >>>> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing >>>> > CPU reg property) Linux can handle single-cell cpu node reg entries >>>> > where /cpus/#address-cells = <1>. >>>> > >>>> > I can't make any guarantees about other code (e.g. bootloaders) which >>>> > might try to do things with cpu nodes, YMMV. >>>> >>>> Ok. If address-cells is kept at 2 the unit address needs to be changed >>>> to "0,0". So one or the other has to be changed. >>> >>> I'm happy either way. >>> >>> I'm not sure the rest of the tree had "0," prefixes on all of the >>> unit-addresses for 64-bit addresses that were under 4GB, and I'm not >>> sure that existing dts consistently do that either. >>> >>> Do we want to enforce that for all 64-bit unit-addresses? >> >> Yeah, I believe that's the only valid format for a 2-address-cell unit address. > > But we don't do leading 0's anywhere else like single cell unit > addresses. Buses expressed with ranges and offsets are one example. > Also, I2C addresses have a 32-bit size in DT yet are only 8-bit and we > don't do leading zero's there. Ok, I'm happily proven wrong here, also by confirming how this is done on "real" OF. According to benh: 15:20 <benh> ojn: 0,0 is not quite right, it's supposed to be used when the two numbers are different things, like device,fn on PCI The same is true for >2^32 unit addresses, they just use the one integer instead of x,y. So, I take back all I've said on this in the last 72 hours. :) It looks like we might need to revisit some of the 32-bit DTs. Simon, drop the series you had. :) -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 22:23 ` Olof Johansson 0 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 22:23 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 10:54 AM, Rob Herring <robh@kernel.org> wrote: > On Thu, Aug 28, 2014 at 12:19 PM, Olof Johansson <olof@lixom.net> wrote: >> On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@arm.com> wrote: >>> On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: >>>> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: >>>> > Hi, >>>> > >>>> >> > + cpus { >>>> >> > + #address-cells = <2>; >>>> >> > + #size-cells = <0>; >>>> >> >>>> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? >>>> > >>>> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing >>>> > CPU reg property) Linux can handle single-cell cpu node reg entries >>>> > where /cpus/#address-cells = <1>. >>>> > >>>> > I can't make any guarantees about other code (e.g. bootloaders) which >>>> > might try to do things with cpu nodes, YMMV. >>>> >>>> Ok. If address-cells is kept at 2 the unit address needs to be changed >>>> to "0,0". So one or the other has to be changed. >>> >>> I'm happy either way. >>> >>> I'm not sure the rest of the tree had "0," prefixes on all of the >>> unit-addresses for 64-bit addresses that were under 4GB, and I'm not >>> sure that existing dts consistently do that either. >>> >>> Do we want to enforce that for all 64-bit unit-addresses? >> >> Yeah, I believe that's the only valid format for a 2-address-cell unit address. > > But we don't do leading 0's anywhere else like single cell unit > addresses. Buses expressed with ranges and offsets are one example. > Also, I2C addresses have a 32-bit size in DT yet are only 8-bit and we > don't do leading zero's there. Ok, I'm happily proven wrong here, also by confirming how this is done on "real" OF. According to benh: 15:20 <benh> ojn: 0,0 is not quite right, it's supposed to be used when the two numbers are different things, like device,fn on PCI The same is true for >2^32 unit addresses, they just use the one integer instead of x,y. So, I take back all I've said on this in the last 72 hours. :) It looks like we might need to revisit some of the 32-bit DTs. Simon, drop the series you had. :) -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 22:23 ` Olof Johansson @ 2014-08-28 23:30 ` Simon Horman -1 siblings, 0 replies; 84+ messages in thread From: Simon Horman @ 2014-08-28 23:30 UTC (permalink / raw) To: Olof Johansson Cc: Rob Herring, Mark Rutland, Marc Zyngier, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Benjamin Herrenschmidt On Thu, Aug 28, 2014 at 03:23:49PM -0700, Olof Johansson wrote: > On Thu, Aug 28, 2014 at 10:54 AM, Rob Herring <robh@kernel.org> wrote: > > On Thu, Aug 28, 2014 at 12:19 PM, Olof Johansson <olof@lixom.net> wrote: > >> On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >>> On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: > >>>> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >>>> > Hi, > >>>> > > >>>> >> > + cpus { > >>>> >> > + #address-cells = <2>; > >>>> >> > + #size-cells = <0>; > >>>> >> > >>>> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? > >>>> > > >>>> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing > >>>> > CPU reg property) Linux can handle single-cell cpu node reg entries > >>>> > where /cpus/#address-cells = <1>. > >>>> > > >>>> > I can't make any guarantees about other code (e.g. bootloaders) which > >>>> > might try to do things with cpu nodes, YMMV. > >>>> > >>>> Ok. If address-cells is kept at 2 the unit address needs to be changed > >>>> to "0,0". So one or the other has to be changed. > >>> > >>> I'm happy either way. > >>> > >>> I'm not sure the rest of the tree had "0," prefixes on all of the > >>> unit-addresses for 64-bit addresses that were under 4GB, and I'm not > >>> sure that existing dts consistently do that either. > >>> > >>> Do we want to enforce that for all 64-bit unit-addresses? > >> > >> Yeah, I believe that's the only valid format for a 2-address-cell unit address. > > > > But we don't do leading 0's anywhere else like single cell unit > > addresses. Buses expressed with ranges and offsets are one example. > > Also, I2C addresses have a 32-bit size in DT yet are only 8-bit and we > > don't do leading zero's there. > > Ok, I'm happily proven wrong here, also by confirming how this is done > on "real" OF. > > According to benh: > > 15:20 <benh> ojn: 0,0 is not quite right, it's supposed to be used > when the two numbers are different things, like device,fn on PCI > > The same is true for >2^32 unit addresses, they just use the one > integer instead of x,y. > > So, I take back all I've said on this in the last 72 hours. :) It > looks like we might need to revisit some of the 32-bit DTs. Simon, > drop the series you had. :) Thanks will do. Is the way forward for me to apply my original patch to change memory@180000000 to memory@140000000? And abandon all the ',' only changes?This one: This is the original patch: From: Simon Horman <horms+renesas@verge.net.au> [PATCH] ARM: shmobile: lager: correct memory map The base address of the second memory region on the lager board is 0x140000000. Update the tag used in the dts file accordingly. This is a documentation fix and should have no run-time affect. This problem was introduced when the second memory region was added to the lager dts file by 62bc32a2573c4219 ("ARM: shmobile: Include all 4 GiB of memory on Lager)" in v3.14. Reported-by: NAOYA SHIIBA <naoya.shiiba.nx@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> --- arch/arm/boot/dts/r8a7790-lager.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts index 0118cbf..84dcafa 100644 --- a/arch/arm/boot/dts/r8a7790-lager.dts +++ b/arch/arm/boot/dts/r8a7790-lager.dts @@ -32,7 +32,7 @@ reg = <0 0x40000000 0 0x40000000>; }; - memory@180000000 { + memory@140000000 { device_type = "memory"; reg = <1 0x40000000 0 0xc0000000>; }; -- 2.0.1 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 23:30 ` Simon Horman 0 siblings, 0 replies; 84+ messages in thread From: Simon Horman @ 2014-08-28 23:30 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 03:23:49PM -0700, Olof Johansson wrote: > On Thu, Aug 28, 2014 at 10:54 AM, Rob Herring <robh@kernel.org> wrote: > > On Thu, Aug 28, 2014 at 12:19 PM, Olof Johansson <olof@lixom.net> wrote: > >> On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >>> On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: > >>>> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >>>> > Hi, > >>>> > > >>>> >> > + cpus { > >>>> >> > + #address-cells = <2>; > >>>> >> > + #size-cells = <0>; > >>>> >> > >>>> >> Why size-cells=2? Can you not fit a cpuid in 32 bits? > >>>> > > >>>> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing > >>>> > CPU reg property) Linux can handle single-cell cpu node reg entries > >>>> > where /cpus/#address-cells = <1>. > >>>> > > >>>> > I can't make any guarantees about other code (e.g. bootloaders) which > >>>> > might try to do things with cpu nodes, YMMV. > >>>> > >>>> Ok. If address-cells is kept at 2 the unit address needs to be changed > >>>> to "0,0". So one or the other has to be changed. > >>> > >>> I'm happy either way. > >>> > >>> I'm not sure the rest of the tree had "0," prefixes on all of the > >>> unit-addresses for 64-bit addresses that were under 4GB, and I'm not > >>> sure that existing dts consistently do that either. > >>> > >>> Do we want to enforce that for all 64-bit unit-addresses? > >> > >> Yeah, I believe that's the only valid format for a 2-address-cell unit address. > > > > But we don't do leading 0's anywhere else like single cell unit > > addresses. Buses expressed with ranges and offsets are one example. > > Also, I2C addresses have a 32-bit size in DT yet are only 8-bit and we > > don't do leading zero's there. > > Ok, I'm happily proven wrong here, also by confirming how this is done > on "real" OF. > > According to benh: > > 15:20 <benh> ojn: 0,0 is not quite right, it's supposed to be used > when the two numbers are different things, like device,fn on PCI > > The same is true for >2^32 unit addresses, they just use the one > integer instead of x,y. > > So, I take back all I've said on this in the last 72 hours. :) It > looks like we might need to revisit some of the 32-bit DTs. Simon, > drop the series you had. :) Thanks will do. Is the way forward for me to apply my original patch to change memory at 180000000 to memory at 140000000? And abandon all the ',' only changes?This one: This is the original patch: From: Simon Horman <horms+renesas@verge.net.au> [PATCH] ARM: shmobile: lager: correct memory map The base address of the second memory region on the lager board is 0x140000000. Update the tag used in the dts file accordingly. This is a documentation fix and should have no run-time affect. This problem was introduced when the second memory region was added to the lager dts file by 62bc32a2573c4219 ("ARM: shmobile: Include all 4 GiB of memory on Lager)" in v3.14. Reported-by: NAOYA SHIIBA <naoya.shiiba.nx@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> --- arch/arm/boot/dts/r8a7790-lager.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts index 0118cbf..84dcafa 100644 --- a/arch/arm/boot/dts/r8a7790-lager.dts +++ b/arch/arm/boot/dts/r8a7790-lager.dts @@ -32,7 +32,7 @@ reg = <0 0x40000000 0 0x40000000>; }; - memory at 180000000 { + memory at 140000000 { device_type = "memory"; reg = <1 0x40000000 0 0xc0000000>; }; -- 2.0.1 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:03 ` Mark Rutland @ 2014-08-28 17:27 ` Marc Zyngier -1 siblings, 0 replies; 84+ messages in thread From: Marc Zyngier @ 2014-08-28 17:27 UTC (permalink / raw) To: Mark Rutland Cc: Olof Johansson, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring On 28/08/14 18:03, Mark Rutland wrote: > From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > From: Mark Rutland <mark.rutland@arm.com> > Date: Thu, 28 Aug 2014 17:41:03 +0100 > Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > > The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > features a CPU register (CNTFRQ) which firmware is intended to > initialize, and non-secure software can read to determine the frequency > of the timer. On CPUs with secure state, this register cannot be written > from non-secure states. > > The firmware of early SoCs featuring the timer did not correctly > initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > described in DT as a workaround. This workaround is not complete however > as CNTFRQ is exposed to all software in a privileged non-secure mode, > including KVM guests. The firmware and DTs for recent SoCs have followed I believe Xen is also affected by this. > the example set by these early SoCs. > > This patch updates the arch timer binding documentation to make it > clearer that the use of the clock-frequency property is a poor > work-around. The MMIO generic timer binding is similarly updated, though > this is less of a concern as there is generally no need to expose the > MMIO timers to guest OSs. > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > Cc: Marc Zyngier <marc.zyngier@arm.com> Short of more explicit threats: Acked-by: Marc Zyngier <marc.zyngier@arm.com> > --- > Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt > index 37b2caf..5ca3f95 100644 > --- a/Documentation/devicetree/bindings/arm/arch_timer.txt > +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt > @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. > - interrupts : Interrupt list for secure, non-secure, virtual and > hypervisor timers, in that order. > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > + only where necessary to work around BROKEN firmware which does not configure > + CNTFRQ on all CPUs to a uniform correct value. Use of this property is > + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. > > - always-on : a boolean property. If present, the timer is powered through an > always-on power domain, therefore it never loses context. > @@ -38,7 +41,8 @@ Example: > > - compatible : Should at least contain "arm,armv7-timer-mem". > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > + only when firmware has not configured the MMIO CNTFRQ registers. > > - reg : The control frame base address. > > -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:27 ` Marc Zyngier 0 siblings, 0 replies; 84+ messages in thread From: Marc Zyngier @ 2014-08-28 17:27 UTC (permalink / raw) To: linux-arm-kernel On 28/08/14 18:03, Mark Rutland wrote: > From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > From: Mark Rutland <mark.rutland@arm.com> > Date: Thu, 28 Aug 2014 17:41:03 +0100 > Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > > The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > features a CPU register (CNTFRQ) which firmware is intended to > initialize, and non-secure software can read to determine the frequency > of the timer. On CPUs with secure state, this register cannot be written > from non-secure states. > > The firmware of early SoCs featuring the timer did not correctly > initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > described in DT as a workaround. This workaround is not complete however > as CNTFRQ is exposed to all software in a privileged non-secure mode, > including KVM guests. The firmware and DTs for recent SoCs have followed I believe Xen is also affected by this. > the example set by these early SoCs. > > This patch updates the arch timer binding documentation to make it > clearer that the use of the clock-frequency property is a poor > work-around. The MMIO generic timer binding is similarly updated, though > this is less of a concern as there is generally no need to expose the > MMIO timers to guest OSs. > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > Cc: Marc Zyngier <marc.zyngier@arm.com> Short of more explicit threats: Acked-by: Marc Zyngier <marc.zyngier@arm.com> > --- > Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt > index 37b2caf..5ca3f95 100644 > --- a/Documentation/devicetree/bindings/arm/arch_timer.txt > +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt > @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. > - interrupts : Interrupt list for secure, non-secure, virtual and > hypervisor timers, in that order. > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > + only where necessary to work around BROKEN firmware which does not configure > + CNTFRQ on all CPUs to a uniform correct value. Use of this property is > + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. > > - always-on : a boolean property. If present, the timer is powered through an > always-on power domain, therefore it never loses context. > @@ -38,7 +41,8 @@ Example: > > - compatible : Should at least contain "arm,armv7-timer-mem". > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > + only when firmware has not configured the MMIO CNTFRQ registers. > > - reg : The control frame base address. > > -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:27 ` Marc Zyngier @ 2014-08-28 17:30 ` Mark Rutland -1 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 17:30 UTC (permalink / raw) To: Marc Zyngier Cc: Olof Johansson, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring On Thu, Aug 28, 2014 at 06:27:04PM +0100, Marc Zyngier wrote: > On 28/08/14 18:03, Mark Rutland wrote: > > > From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > > From: Mark Rutland <mark.rutland@arm.com> > > Date: Thu, 28 Aug 2014 17:41:03 +0100 > > Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > > > > The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > > features a CPU register (CNTFRQ) which firmware is intended to > > initialize, and non-secure software can read to determine the frequency > > of the timer. On CPUs with secure state, this register cannot be written > > from non-secure states. > > > > The firmware of early SoCs featuring the timer did not correctly > > initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > > described in DT as a workaround. This workaround is not complete however > > as CNTFRQ is exposed to all software in a privileged non-secure mode, > > including KVM guests. The firmware and DTs for recent SoCs have followed > > I believe Xen is also affected by this. True. s/KVM/KVM\/Xen/, then? > > the example set by these early SoCs. > > > > This patch updates the arch timer binding documentation to make it > > clearer that the use of the clock-frequency property is a poor > > work-around. The MMIO generic timer binding is similarly updated, though > > this is less of a concern as there is generally no need to expose the > > MMIO timers to guest OSs. > > > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > > Cc: Marc Zyngier <marc.zyngier@arm.com> > > Short of more explicit threats: > > Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cheers. Mark. > > > --- > > Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt > > index 37b2caf..5ca3f95 100644 > > --- a/Documentation/devicetree/bindings/arm/arch_timer.txt > > +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt > > @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. > > - interrupts : Interrupt list for secure, non-secure, virtual and > > hypervisor timers, in that order. > > > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > > + only where necessary to work around BROKEN firmware which does not configure > > + CNTFRQ on all CPUs to a uniform correct value. Use of this property is > > + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. > > > > - always-on : a boolean property. If present, the timer is powered through an > > always-on power domain, therefore it never loses context. > > @@ -38,7 +41,8 @@ Example: > > > > - compatible : Should at least contain "arm,armv7-timer-mem". > > > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > > + only when firmware has not configured the MMIO CNTFRQ registers. > > > > - reg : The control frame base address. > > > > > > > -- > Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:30 ` Mark Rutland 0 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 17:30 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 06:27:04PM +0100, Marc Zyngier wrote: > On 28/08/14 18:03, Mark Rutland wrote: > > > From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > > From: Mark Rutland <mark.rutland@arm.com> > > Date: Thu, 28 Aug 2014 17:41:03 +0100 > > Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > > > > The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > > features a CPU register (CNTFRQ) which firmware is intended to > > initialize, and non-secure software can read to determine the frequency > > of the timer. On CPUs with secure state, this register cannot be written > > from non-secure states. > > > > The firmware of early SoCs featuring the timer did not correctly > > initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > > described in DT as a workaround. This workaround is not complete however > > as CNTFRQ is exposed to all software in a privileged non-secure mode, > > including KVM guests. The firmware and DTs for recent SoCs have followed > > I believe Xen is also affected by this. True. s/KVM/KVM\/Xen/, then? > > the example set by these early SoCs. > > > > This patch updates the arch timer binding documentation to make it > > clearer that the use of the clock-frequency property is a poor > > work-around. The MMIO generic timer binding is similarly updated, though > > this is less of a concern as there is generally no need to expose the > > MMIO timers to guest OSs. > > > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > > Cc: Marc Zyngier <marc.zyngier@arm.com> > > Short of more explicit threats: > > Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cheers. Mark. > > > --- > > Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt > > index 37b2caf..5ca3f95 100644 > > --- a/Documentation/devicetree/bindings/arm/arch_timer.txt > > +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt > > @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. > > - interrupts : Interrupt list for secure, non-secure, virtual and > > hypervisor timers, in that order. > > > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > > + only where necessary to work around BROKEN firmware which does not configure > > + CNTFRQ on all CPUs to a uniform correct value. Use of this property is > > + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. > > > > - always-on : a boolean property. If present, the timer is powered through an > > always-on power domain, therefore it never loses context. > > @@ -38,7 +41,8 @@ Example: > > > > - compatible : Should at least contain "arm,armv7-timer-mem". > > > > -- clock-frequency : The frequency of the main counter, in Hz. Optional. > > +- clock-frequency : The frequency of the main counter, in Hz. Should be present > > + only when firmware has not configured the MMIO CNTFRQ registers. > > > > - reg : The control frame base address. > > > > > > > -- > Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:30 ` Mark Rutland @ 2014-08-28 17:37 ` Marc Zyngier -1 siblings, 0 replies; 84+ messages in thread From: Marc Zyngier @ 2014-08-28 17:37 UTC (permalink / raw) To: Mark Rutland Cc: Olof Johansson, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring On 28/08/14 18:30, Mark Rutland wrote: > On Thu, Aug 28, 2014 at 06:27:04PM +0100, Marc Zyngier wrote: >> On 28/08/14 18:03, Mark Rutland wrote: >> >>> From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 >>> From: Mark Rutland <mark.rutland@arm.com> >>> Date: Thu, 28 Aug 2014 17:41:03 +0100 >>> Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use >>> >>> The ARM Generic Timer (AKA the architected timer, arm_arch_timer) >>> features a CPU register (CNTFRQ) which firmware is intended to >>> initialize, and non-secure software can read to determine the frequency >>> of the timer. On CPUs with secure state, this register cannot be written >>> from non-secure states. >>> >>> The firmware of early SoCs featuring the timer did not correctly >>> initialize CNTFRQ correctly on all CPUs, requiring the frequency to be >>> described in DT as a workaround. This workaround is not complete however >>> as CNTFRQ is exposed to all software in a privileged non-secure mode, >>> including KVM guests. The firmware and DTs for recent SoCs have followed >> >> I believe Xen is also affected by this. > > True. > > s/KVM/KVM\/Xen/, then? Yup. Or "including guests running under a hypervisor", I expect this to be such a fundamental problem that all hypervisors will trip over on that one (Jailhouse definitely does). Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:37 ` Marc Zyngier 0 siblings, 0 replies; 84+ messages in thread From: Marc Zyngier @ 2014-08-28 17:37 UTC (permalink / raw) To: linux-arm-kernel On 28/08/14 18:30, Mark Rutland wrote: > On Thu, Aug 28, 2014 at 06:27:04PM +0100, Marc Zyngier wrote: >> On 28/08/14 18:03, Mark Rutland wrote: >> >>> From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 >>> From: Mark Rutland <mark.rutland@arm.com> >>> Date: Thu, 28 Aug 2014 17:41:03 +0100 >>> Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use >>> >>> The ARM Generic Timer (AKA the architected timer, arm_arch_timer) >>> features a CPU register (CNTFRQ) which firmware is intended to >>> initialize, and non-secure software can read to determine the frequency >>> of the timer. On CPUs with secure state, this register cannot be written >>> from non-secure states. >>> >>> The firmware of early SoCs featuring the timer did not correctly >>> initialize CNTFRQ correctly on all CPUs, requiring the frequency to be >>> described in DT as a workaround. This workaround is not complete however >>> as CNTFRQ is exposed to all software in a privileged non-secure mode, >>> including KVM guests. The firmware and DTs for recent SoCs have followed >> >> I believe Xen is also affected by this. > > True. > > s/KVM/KVM\/Xen/, then? Yup. Or "including guests running under a hypervisor", I expect this to be such a fundamental problem that all hypervisors will trip over on that one (Jailhouse definitely does). Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:37 ` Marc Zyngier @ 2014-08-28 17:45 ` Mark Rutland -1 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 17:45 UTC (permalink / raw) To: Marc Zyngier Cc: Olof Johansson, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring On Thu, Aug 28, 2014 at 06:37:19PM +0100, Marc Zyngier wrote: > On 28/08/14 18:30, Mark Rutland wrote: > > On Thu, Aug 28, 2014 at 06:27:04PM +0100, Marc Zyngier wrote: > >> On 28/08/14 18:03, Mark Rutland wrote: > >> > >>> From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > >>> From: Mark Rutland <mark.rutland@arm.com> > >>> Date: Thu, 28 Aug 2014 17:41:03 +0100 > >>> Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > >>> > >>> The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > >>> features a CPU register (CNTFRQ) which firmware is intended to > >>> initialize, and non-secure software can read to determine the frequency > >>> of the timer. On CPUs with secure state, this register cannot be written > >>> from non-secure states. > >>> > >>> The firmware of early SoCs featuring the timer did not correctly > >>> initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > >>> described in DT as a workaround. This workaround is not complete however > >>> as CNTFRQ is exposed to all software in a privileged non-secure mode, > >>> including KVM guests. The firmware and DTs for recent SoCs have followed > >> > >> I believe Xen is also affected by this. > > > > True. > > > > s/KVM/KVM\/Xen/, then? > > Yup. Or "including guests running under a hypervisor" Ah, that sounds better. I'll use that for the next posting. > I expect this to be such a fundamental problem that all hypervisors > will trip over on that one (Jailhouse definitely does). Yeah, this is a generic problem. Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:45 ` Mark Rutland 0 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 17:45 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 06:37:19PM +0100, Marc Zyngier wrote: > On 28/08/14 18:30, Mark Rutland wrote: > > On Thu, Aug 28, 2014 at 06:27:04PM +0100, Marc Zyngier wrote: > >> On 28/08/14 18:03, Mark Rutland wrote: > >> > >>> From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > >>> From: Mark Rutland <mark.rutland@arm.com> > >>> Date: Thu, 28 Aug 2014 17:41:03 +0100 > >>> Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > >>> > >>> The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > >>> features a CPU register (CNTFRQ) which firmware is intended to > >>> initialize, and non-secure software can read to determine the frequency > >>> of the timer. On CPUs with secure state, this register cannot be written > >>> from non-secure states. > >>> > >>> The firmware of early SoCs featuring the timer did not correctly > >>> initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > >>> described in DT as a workaround. This workaround is not complete however > >>> as CNTFRQ is exposed to all software in a privileged non-secure mode, > >>> including KVM guests. The firmware and DTs for recent SoCs have followed > >> > >> I believe Xen is also affected by this. > > > > True. > > > > s/KVM/KVM\/Xen/, then? > > Yup. Or "including guests running under a hypervisor" Ah, that sounds better. I'll use that for the next posting. > I expect this to be such a fundamental problem that all hypervisors > will trip over on that one (Jailhouse definitely does). Yeah, this is a generic problem. Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <53FF6668.4080502-5wv7dgnIgG8@public.gmane.org>]
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:27 ` Marc Zyngier @ 2014-08-28 17:33 ` Rob Herring -1 siblings, 0 replies; 84+ messages in thread From: Rob Herring @ 2014-08-28 17:33 UTC (permalink / raw) To: Marc Zyngier Cc: Mark Rutland, Olof Johansson, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch-Re5JQEeQqe8AvxtiuMwx3w, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, cpgs-Sze3O3UU22JBDgjK7y7TUQ, Thomas Abraham On Thu, Aug 28, 2014 at 12:27 PM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: > On 28/08/14 18:03, Mark Rutland wrote: > >> From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> >> Date: Thu, 28 Aug 2014 17:41:03 +0100 >> Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use >> >> The ARM Generic Timer (AKA the architected timer, arm_arch_timer) >> features a CPU register (CNTFRQ) which firmware is intended to >> initialize, and non-secure software can read to determine the frequency >> of the timer. On CPUs with secure state, this register cannot be written >> from non-secure states. >> >> The firmware of early SoCs featuring the timer did not correctly >> initialize CNTFRQ correctly on all CPUs, requiring the frequency to be >> described in DT as a workaround. This workaround is not complete however >> as CNTFRQ is exposed to all software in a privileged non-secure mode, >> including KVM guests. The firmware and DTs for recent SoCs have followed > > I believe Xen is also affected by this. > >> the example set by these early SoCs. >> >> This patch updates the arch timer binding documentation to make it >> clearer that the use of the clock-frequency property is a poor >> work-around. The MMIO generic timer binding is similarly updated, though >> this is less of a concern as there is generally no need to expose the >> MMIO timers to guest OSs. >> >> Signed-off-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> >> Cc: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> > > Short of more explicit threats: Why not also add WARNs (and mark for stable). People tend to notice and fix those. If not the vendors, those pesky customers always complain (the same ones that get concerned about BogoMIPS values being too low). Rob -- 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] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:33 ` Rob Herring 0 siblings, 0 replies; 84+ messages in thread From: Rob Herring @ 2014-08-28 17:33 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 12:27 PM, Marc Zyngier <marc.zyngier@arm.com> wrote: > On 28/08/14 18:03, Mark Rutland wrote: > >> From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 >> From: Mark Rutland <mark.rutland@arm.com> >> Date: Thu, 28 Aug 2014 17:41:03 +0100 >> Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use >> >> The ARM Generic Timer (AKA the architected timer, arm_arch_timer) >> features a CPU register (CNTFRQ) which firmware is intended to >> initialize, and non-secure software can read to determine the frequency >> of the timer. On CPUs with secure state, this register cannot be written >> from non-secure states. >> >> The firmware of early SoCs featuring the timer did not correctly >> initialize CNTFRQ correctly on all CPUs, requiring the frequency to be >> described in DT as a workaround. This workaround is not complete however >> as CNTFRQ is exposed to all software in a privileged non-secure mode, >> including KVM guests. The firmware and DTs for recent SoCs have followed > > I believe Xen is also affected by this. > >> the example set by these early SoCs. >> >> This patch updates the arch timer binding documentation to make it >> clearer that the use of the clock-frequency property is a poor >> work-around. The MMIO generic timer binding is similarly updated, though >> this is less of a concern as there is generally no need to expose the >> MMIO timers to guest OSs. >> >> Signed-off-by: Mark Rutland <mark.rutland@arm.com> >> Cc: Marc Zyngier <marc.zyngier@arm.com> > > Short of more explicit threats: Why not also add WARNs (and mark for stable). People tend to notice and fix those. If not the vendors, those pesky customers always complain (the same ones that get concerned about BogoMIPS values being too low). Rob ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 17:33 ` Rob Herring @ 2014-08-28 17:43 ` Mark Rutland -1 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 17:43 UTC (permalink / raw) To: Rob Herring Cc: Marc Zyngier, Olof Johansson, Naveen Krishna Chatradhi, Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham On Thu, Aug 28, 2014 at 06:33:13PM +0100, Rob Herring wrote: > On Thu, Aug 28, 2014 at 12:27 PM, Marc Zyngier <marc.zyngier@arm.com> wrote: > > On 28/08/14 18:03, Mark Rutland wrote: > > > >> From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > >> From: Mark Rutland <mark.rutland@arm.com> > >> Date: Thu, 28 Aug 2014 17:41:03 +0100 > >> Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > >> > >> The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > >> features a CPU register (CNTFRQ) which firmware is intended to > >> initialize, and non-secure software can read to determine the frequency > >> of the timer. On CPUs with secure state, this register cannot be written > >> from non-secure states. > >> > >> The firmware of early SoCs featuring the timer did not correctly > >> initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > >> described in DT as a workaround. This workaround is not complete however > >> as CNTFRQ is exposed to all software in a privileged non-secure mode, > >> including KVM guests. The firmware and DTs for recent SoCs have followed > > > > I believe Xen is also affected by this. > > > >> the example set by these early SoCs. > >> > >> This patch updates the arch timer binding documentation to make it > >> clearer that the use of the clock-frequency property is a poor > >> work-around. The MMIO generic timer binding is similarly updated, though > >> this is less of a concern as there is generally no need to expose the > >> MMIO timers to guest OSs. > >> > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com> > >> Cc: Marc Zyngier <marc.zyngier@arm.com> > > > > Short of more explicit threats: > > Why not also add WARNs (and mark for stable). People tend to notice > and fix those. If not the vendors, those pesky customers always > complain (the same ones that get concerned about BogoMIPS values being > too low). I had a go a while back but it was a bit painful becuase the MMIO and cpu timer code is intertwined, and a clock-frequency property on the MMIO timers isn't all that problematic (though admittedly still a workaround for FW not initialising something it was intended to). I was hoping I'd have the chance to split the driver in two first, so as to sidestep that. I'll take another look. Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-08-28 17:43 ` Mark Rutland 0 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-28 17:43 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 28, 2014 at 06:33:13PM +0100, Rob Herring wrote: > On Thu, Aug 28, 2014 at 12:27 PM, Marc Zyngier <marc.zyngier@arm.com> wrote: > > On 28/08/14 18:03, Mark Rutland wrote: > > > >> From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 > >> From: Mark Rutland <mark.rutland@arm.com> > >> Date: Thu, 28 Aug 2014 17:41:03 +0100 > >> Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use > >> > >> The ARM Generic Timer (AKA the architected timer, arm_arch_timer) > >> features a CPU register (CNTFRQ) which firmware is intended to > >> initialize, and non-secure software can read to determine the frequency > >> of the timer. On CPUs with secure state, this register cannot be written > >> from non-secure states. > >> > >> The firmware of early SoCs featuring the timer did not correctly > >> initialize CNTFRQ correctly on all CPUs, requiring the frequency to be > >> described in DT as a workaround. This workaround is not complete however > >> as CNTFRQ is exposed to all software in a privileged non-secure mode, > >> including KVM guests. The firmware and DTs for recent SoCs have followed > > > > I believe Xen is also affected by this. > > > >> the example set by these early SoCs. > >> > >> This patch updates the arch timer binding documentation to make it > >> clearer that the use of the clock-frequency property is a poor > >> work-around. The MMIO generic timer binding is similarly updated, though > >> this is less of a concern as there is generally no need to expose the > >> MMIO timers to guest OSs. > >> > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com> > >> Cc: Marc Zyngier <marc.zyngier@arm.com> > > > > Short of more explicit threats: > > Why not also add WARNs (and mark for stable). People tend to notice > and fix those. If not the vendors, those pesky customers always > complain (the same ones that get concerned about BogoMIPS values being > too low). I had a go a while back but it was a bit painful becuase the MMIO and cpu timer code is intertwined, and a clock-frequency property on the MMIO timers isn't all that problematic (though admittedly still a workaround for FW not initialising something it was intended to). I was hoping I'd have the chance to split the driver in two first, so as to sidestep that. I'll take another look. Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 2014-08-28 3:56 ` Olof Johansson @ 2014-09-03 8:05 ` Naveen Krishna Ch -1 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-09-03 8:05 UTC (permalink / raw) To: Olof Johansson Cc: Naveen Krishna Chatradhi, catalin.marinas, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Thomas Abraham, Rob Herring Hi Olof, On 28 August 2014 09:26, Olof Johansson <olof@lixom.net> wrote: > Hi, > > On Wed, Aug 27, 2014 at 03:14:18PM +0530, Naveen Krishna Chatradhi wrote: >> Add initial device tree nodes for EXYNOS7 SoC. >> Also, includes the dt-binding definitions for clock ids. > > Uh, no -- it just adds the dtsi. Ok. Will fix. > >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Thomas Abraham <thomas.ab@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 553 insertions(+) >> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi >> >> diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi >> new file mode 100644 >> index 0000000..6b9eaf4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/exynos7.dtsi > > Let's not make the same mistake as on 32-bit, and go with a directory > hierarchy here from day one. > > So, please create a exynos subdirectory for this file. You also need > a Makefile when you add a board dts. Ok. Will fix. > >> @@ -0,0 +1,553 @@ >> +/* >> + * SAMSUNG EXYNOS7 SoC device tree source >> + * >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. >> + * EXYNOS7 based board files can include this file and provide >> + * values for board specfic bindings. >> + * >> + * 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 <dt-bindings/clock/exynos7-clk.h> >> + >> +/ { >> + compatible = "samsung,exynos7"; >> + interrupt-parent = <&gic>; >> + #address-cells = <1>; >> + #size-cells = <1>; > > You should probably use address-cells/size-cells 2/2 on a 64-bit platform. Ok. > >> + aliases { >> + pinctrl0 = &pinctrl_0; >> + pinctrl1 = &pinctrl_1; >> + pinctrl2 = &pinctrl_2; >> + pinctrl3 = &pinctrl_3; >> + pinctrl4 = &pinctrl_4; >> + pinctrl5 = &pinctrl_5; >> + pinctrl6 = &pinctrl_6; >> + pinctrl7 = &pinctrl_7; >> + pinctrl8 = &pinctrl_8; >> + pinctrl9 = &pinctrl_9; >> + mshc0 = &mmc_0; >> + mshc2 = &mmc_2; >> + }; >> + >> + chipid@10000000 { >> + compatible = "samsung,exynos4210-chipid"; >> + reg = <0x10000000 0x100>; >> + }; >> + >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; > > Why size-cells=2? Can you not fit a cpuid in 32 bits? > >> + cpu@0 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a57", "arm,armv8"; >> + reg = <0x0 0x0>; >> + }; >> + }; >> + >> + fin_pll: xxti { >> + compatible = "fixed-clock"; >> + clock-frequency = <24000000>; >> + clock-output-names = "fin_pll"; >> + #clock-cells = <0>; >> + }; >> + >> + gic: interrupt-controller@11001000 { >> + compatible = "arm,gic-400"; >> + #interrupt-cells = <3>; >> + #address-cells = <0>; >> + interrupt-controller; >> + reg = <0x11001000 0x1000>, >> + <0x11002000 0x1000>, >> + <0x11004000 0x2000>, >> + <0x11006000 0x2000>; >> + }; >> + >> + hsi2c_0: hsi2c@13640000 { >> + compatible = "samsung,exynos7-hsi2c"; > > Is the i2c controller here completely new? It is almost the same as in Exynos5 but few register bits have been changed. So we have added a new compatible string. > > Also, please use 'i2c' for node name on these nodes. Ok. > >> + reg = <0x13640000 0x1000>; >> + interrupts = <0 441 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&hs_i2c0_bus>; >> + clocks = <&clock_peric0 PCLK_HSI2C0>; >> + clock-names = "hsi2c"; >> + status = "disabled"; >> + }; >> + >> + hsi2c_1: hsi2c@13650000 { >> + compatible = "samsung,exynos7-hsi2c"; >> + reg = <0x13650000 0x1000>; >> + interrupts = <0 442 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&hs_i2c1_bus>; >> + clocks = <&clock_peric0 PCLK_HSI2C1>; >> + clock-names = "hsi2c"; >> + status = "disabled"; >> + }; >> + >> + hsi2c_2: hsi2c@14E60000 { > > I much prefer lowercase hex in unit addresses (and reg entries) below. I > know 32-bit uses uppercase, but let's switch going forward here. Ok. Will fix. > >> + mct@101C0000 { >> + compatible = "samsung,exynos4210-mct"; > > Please just do away with MCT here, and use architected timers going > forward. There really shouldn't be a need to keep supporting MCT any > more -- it's a construct from before arch timers on Cortex-A9. Ok. > >> + mmc_0: mmc@15740000 { >> + compatible = "samsung,exynos7-dw-mshc-smu"; > > Is this controller backwards compatible with exynos5 ones? The dwmmc controller in Exynos7 is not fully backward compatible with Exynos5. Specifically, it requires 64-bit related changes for IDMAC and handling the changes in register offsets. > >> + /* The Clock nodes are ordered as per the usermanual. */ > > "The clock" > > "user manual" Ok. > >> + timer { >> + compatible = "arm,armv8-timer"; >> + interrupts = <1 13 0xff01>, >> + <1 14 0xff01>, >> + <1 11 0xff01>, >> + <1 10 0xff01>; >> + clock-frequency = <24000000>; >> + use-clocksource-only; >> + use-physical-timer; > > These two properties are not standard, and I would expect any 64-bit > platform to come with PSCI such that you have a way to initialize the > virtual timers. Ok. > > > -Olof Thanks for your comments. -- Shine bright, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 @ 2014-09-03 8:05 ` Naveen Krishna Ch 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-09-03 8:05 UTC (permalink / raw) To: linux-arm-kernel Hi Olof, On 28 August 2014 09:26, Olof Johansson <olof@lixom.net> wrote: > Hi, > > On Wed, Aug 27, 2014 at 03:14:18PM +0530, Naveen Krishna Chatradhi wrote: >> Add initial device tree nodes for EXYNOS7 SoC. >> Also, includes the dt-binding definitions for clock ids. > > Uh, no -- it just adds the dtsi. Ok. Will fix. > >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Thomas Abraham <thomas.ab@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/exynos7.dtsi | 553 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 553 insertions(+) >> create mode 100644 arch/arm64/boot/dts/exynos7.dtsi >> >> diff --git a/arch/arm64/boot/dts/exynos7.dtsi b/arch/arm64/boot/dts/exynos7.dtsi >> new file mode 100644 >> index 0000000..6b9eaf4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/exynos7.dtsi > > Let's not make the same mistake as on 32-bit, and go with a directory > hierarchy here from day one. > > So, please create a exynos subdirectory for this file. You also need > a Makefile when you add a board dts. Ok. Will fix. > >> @@ -0,0 +1,553 @@ >> +/* >> + * SAMSUNG EXYNOS7 SoC device tree source >> + * >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * SAMSUNG EXYNOS7 SoC device nodes are listed in this file. >> + * EXYNOS7 based board files can include this file and provide >> + * values for board specfic bindings. >> + * >> + * 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 <dt-bindings/clock/exynos7-clk.h> >> + >> +/ { >> + compatible = "samsung,exynos7"; >> + interrupt-parent = <&gic>; >> + #address-cells = <1>; >> + #size-cells = <1>; > > You should probably use address-cells/size-cells 2/2 on a 64-bit platform. Ok. > >> + aliases { >> + pinctrl0 = &pinctrl_0; >> + pinctrl1 = &pinctrl_1; >> + pinctrl2 = &pinctrl_2; >> + pinctrl3 = &pinctrl_3; >> + pinctrl4 = &pinctrl_4; >> + pinctrl5 = &pinctrl_5; >> + pinctrl6 = &pinctrl_6; >> + pinctrl7 = &pinctrl_7; >> + pinctrl8 = &pinctrl_8; >> + pinctrl9 = &pinctrl_9; >> + mshc0 = &mmc_0; >> + mshc2 = &mmc_2; >> + }; >> + >> + chipid at 10000000 { >> + compatible = "samsung,exynos4210-chipid"; >> + reg = <0x10000000 0x100>; >> + }; >> + >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; > > Why size-cells=2? Can you not fit a cpuid in 32 bits? > >> + cpu at 0 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a57", "arm,armv8"; >> + reg = <0x0 0x0>; >> + }; >> + }; >> + >> + fin_pll: xxti { >> + compatible = "fixed-clock"; >> + clock-frequency = <24000000>; >> + clock-output-names = "fin_pll"; >> + #clock-cells = <0>; >> + }; >> + >> + gic: interrupt-controller at 11001000 { >> + compatible = "arm,gic-400"; >> + #interrupt-cells = <3>; >> + #address-cells = <0>; >> + interrupt-controller; >> + reg = <0x11001000 0x1000>, >> + <0x11002000 0x1000>, >> + <0x11004000 0x2000>, >> + <0x11006000 0x2000>; >> + }; >> + >> + hsi2c_0: hsi2c at 13640000 { >> + compatible = "samsung,exynos7-hsi2c"; > > Is the i2c controller here completely new? It is almost the same as in Exynos5 but few register bits have been changed. So we have added a new compatible string. > > Also, please use 'i2c' for node name on these nodes. Ok. > >> + reg = <0x13640000 0x1000>; >> + interrupts = <0 441 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&hs_i2c0_bus>; >> + clocks = <&clock_peric0 PCLK_HSI2C0>; >> + clock-names = "hsi2c"; >> + status = "disabled"; >> + }; >> + >> + hsi2c_1: hsi2c at 13650000 { >> + compatible = "samsung,exynos7-hsi2c"; >> + reg = <0x13650000 0x1000>; >> + interrupts = <0 442 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&hs_i2c1_bus>; >> + clocks = <&clock_peric0 PCLK_HSI2C1>; >> + clock-names = "hsi2c"; >> + status = "disabled"; >> + }; >> + >> + hsi2c_2: hsi2c at 14E60000 { > > I much prefer lowercase hex in unit addresses (and reg entries) below. I > know 32-bit uses uppercase, but let's switch going forward here. Ok. Will fix. > >> + mct at 101C0000 { >> + compatible = "samsung,exynos4210-mct"; > > Please just do away with MCT here, and use architected timers going > forward. There really shouldn't be a need to keep supporting MCT any > more -- it's a construct from before arch timers on Cortex-A9. Ok. > >> + mmc_0: mmc at 15740000 { >> + compatible = "samsung,exynos7-dw-mshc-smu"; > > Is this controller backwards compatible with exynos5 ones? The dwmmc controller in Exynos7 is not fully backward compatible with Exynos5. Specifically, it requires 64-bit related changes for IDMAC and handling the changes in register offsets. > >> + /* The Clock nodes are ordered as per the usermanual. */ > > "The clock" > > "user manual" Ok. > >> + timer { >> + compatible = "arm,armv8-timer"; >> + interrupts = <1 13 0xff01>, >> + <1 14 0xff01>, >> + <1 11 0xff01>, >> + <1 10 0xff01>; >> + clock-frequency = <24000000>; >> + use-clocksource-only; >> + use-physical-timer; > > These two properties are not standard, and I would expect any 64-bit > platform to come with PSCI such that you have a way to initialize the > virtual timers. Ok. > > > -Olof Thanks for your comments. -- Shine bright, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 12/14] arm64: dts: add Exynos7 based Espresso board dts file 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-27 9:44 ` Naveen Krishna Chatradhi -1 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Chatradhi @ 2014-08-27 9:44 UTC (permalink / raw) To: catalin.marinas Cc: naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Rob Herring This patch adds initial dts file for the Espresso board based on Exynos7 from Samsung. Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Cc: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/exynos7-espresso.dts | 69 ++++++++++++++++++++++++++++++ 2 files changed, 70 insertions(+) create mode 100644 arch/arm64/boot/dts/exynos7-espresso.dts diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index c52bdb0..d160de1 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -1,5 +1,6 @@ dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb +dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb targets += dtbs targets += $(dtb-y) diff --git a/arch/arm64/boot/dts/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos7-espresso.dts new file mode 100644 index 0000000..e35e83c --- /dev/null +++ b/arch/arm64/boot/dts/exynos7-espresso.dts @@ -0,0 +1,69 @@ +/* + * SAMSUNG Espresso board device tree source + * + * Copyright (c) 2014 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 <dt-bindings/gpio/gpio.h> +#include "exynos7.dtsi" + +/ { + model = "Samsung ESPRESSO board based on EXYNOS7"; + compatible = "samsung,espresso", "samsung,exynos7"; + + chosen { + bootargs = "console=ttySAC2,115200n8 root=/dev/ram0 ramdisk=16384 initrd=0x42000000,16M init=/linuxrc"; + }; + + memory@40000000 { + device_type = "memory"; + reg = <0x40000000 0xC0000000>; + }; + + mmc@15740000 { + status = "okay"; + num-slots = <1>; + broken-cd; + caps2-mmc-hs200-1_8v; + supports-highspeed; + non-removable; + card-detect-delay = <200>; + clock-frequency = <800000000>; + 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_clk &sd0_cmd &sd0_rdqs &sd0_bus1 &sd0_bus4 &sd0_bus8>; + bus-width = <8>; + + slot@0 { + reg = <0>; + bus-width = <8>; + }; + }; + + mmc@15560000 { + num-slots = <1>; + supports-highspeed; + card-detect-delay = <200>; + clock-frequency = <400000000>; + 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>; + bus-width = <4>; + + slot@0 { + reg = <0>; + disable-wp; + bus-width = <4>; + }; + }; +}; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 12/14] arm64: dts: add Exynos7 based Espresso board dts file @ 2014-08-27 9:44 ` Naveen Krishna Chatradhi 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Chatradhi @ 2014-08-27 9:44 UTC (permalink / raw) To: linux-arm-kernel This patch adds initial dts file for the Espresso board based on Exynos7 from Samsung. Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Cc: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/exynos7-espresso.dts | 69 ++++++++++++++++++++++++++++++ 2 files changed, 70 insertions(+) create mode 100644 arch/arm64/boot/dts/exynos7-espresso.dts diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index c52bdb0..d160de1 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -1,5 +1,6 @@ dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb +dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb targets += dtbs targets += $(dtb-y) diff --git a/arch/arm64/boot/dts/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos7-espresso.dts new file mode 100644 index 0000000..e35e83c --- /dev/null +++ b/arch/arm64/boot/dts/exynos7-espresso.dts @@ -0,0 +1,69 @@ +/* + * SAMSUNG Espresso board device tree source + * + * Copyright (c) 2014 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 <dt-bindings/gpio/gpio.h> +#include "exynos7.dtsi" + +/ { + model = "Samsung ESPRESSO board based on EXYNOS7"; + compatible = "samsung,espresso", "samsung,exynos7"; + + chosen { + bootargs = "console=ttySAC2,115200n8 root=/dev/ram0 ramdisk=16384 initrd=0x42000000,16M init=/linuxrc"; + }; + + memory at 40000000 { + device_type = "memory"; + reg = <0x40000000 0xC0000000>; + }; + + mmc at 15740000 { + status = "okay"; + num-slots = <1>; + broken-cd; + caps2-mmc-hs200-1_8v; + supports-highspeed; + non-removable; + card-detect-delay = <200>; + clock-frequency = <800000000>; + 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_clk &sd0_cmd &sd0_rdqs &sd0_bus1 &sd0_bus4 &sd0_bus8>; + bus-width = <8>; + + slot at 0 { + reg = <0>; + bus-width = <8>; + }; + }; + + mmc at 15560000 { + num-slots = <1>; + supports-highspeed; + card-detect-delay = <200>; + clock-frequency = <400000000>; + 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>; + bus-width = <4>; + + slot at 0 { + reg = <0>; + disable-wp; + bus-width = <4>; + }; + }; +}; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: [PATCH 12/14] arm64: dts: add Exynos7 based Espresso board dts file 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-27 11:32 ` Tomasz Figa -1 siblings, 0 replies; 84+ messages in thread From: Tomasz Figa @ 2014-08-27 11:32 UTC (permalink / raw) To: Naveen Krishna Chatradhi, catalin.marinas Cc: naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Rob Herring Hi Naveen, Please see my comments inline. On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: > This patch adds initial dts file for the Espresso board > based on Exynos7 from Samsung. [snip] > + mmc@15740000 { Please migrate this dts file to the reference-based syntax. > + status = "okay"; > + num-slots = <1>; > + broken-cd; > + caps2-mmc-hs200-1_8v; > + supports-highspeed; > + non-removable; > + card-detect-delay = <200>; > + clock-frequency = <800000000>; > + 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_clk &sd0_cmd &sd0_rdqs &sd0_bus1 &sd0_bus4 &sd0_bus8>; > + bus-width = <8>; > + > + slot@0 { > + reg = <0>; > + bus-width = <8>; Why is bus-width repeated? Best regards, Tomasz ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 12/14] arm64: dts: add Exynos7 based Espresso board dts file @ 2014-08-27 11:32 ` Tomasz Figa 0 siblings, 0 replies; 84+ messages in thread From: Tomasz Figa @ 2014-08-27 11:32 UTC (permalink / raw) To: linux-arm-kernel Hi Naveen, Please see my comments inline. On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: > This patch adds initial dts file for the Espresso board > based on Exynos7 from Samsung. [snip] > + mmc at 15740000 { Please migrate this dts file to the reference-based syntax. > + status = "okay"; > + num-slots = <1>; > + broken-cd; > + caps2-mmc-hs200-1_8v; > + supports-highspeed; > + non-removable; > + card-detect-delay = <200>; > + clock-frequency = <800000000>; > + 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_clk &sd0_cmd &sd0_rdqs &sd0_bus1 &sd0_bus4 &sd0_bus8>; > + bus-width = <8>; > + > + slot at 0 { > + reg = <0>; > + bus-width = <8>; Why is bus-width repeated? Best regards, Tomasz ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 12/14] arm64: dts: add Exynos7 based Espresso board dts file 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-28 4:00 ` Olof Johansson -1 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 4:00 UTC (permalink / raw) To: Naveen Krishna Chatradhi Cc: catalin.marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Rob Herring Hi, On Wed, Aug 27, 2014 at 03:14:19PM +0530, Naveen Krishna Chatradhi wrote: > This patch adds initial dts file for the Espresso board > based on Exynos7 from Samsung. > > Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/boot/dts/Makefile | 1 + > arch/arm64/boot/dts/exynos7-espresso.dts | 69 ++++++++++++++++++++++++++++++ > 2 files changed, 70 insertions(+) > create mode 100644 arch/arm64/boot/dts/exynos7-espresso.dts > > diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile > index c52bdb0..d160de1 100644 > --- a/arch/arm64/boot/dts/Makefile > +++ b/arch/arm64/boot/dts/Makefile > @@ -1,5 +1,6 @@ > dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb > dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb > +dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb As mentioned on the dtsi patch, please create a subdirectory. > targets += dtbs > targets += $(dtb-y) > diff --git a/arch/arm64/boot/dts/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos7-espresso.dts > new file mode 100644 > index 0000000..e35e83c > --- /dev/null > +++ b/arch/arm64/boot/dts/exynos7-espresso.dts > @@ -0,0 +1,69 @@ > +/* > + * SAMSUNG Espresso board device tree source > + * > + * Copyright (c) 2014 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 <dt-bindings/gpio/gpio.h> > +#include "exynos7.dtsi" > + > +/ { > + model = "Samsung ESPRESSO board based on EXYNOS7"; > + compatible = "samsung,espresso", "samsung,exynos7"; > + > + chosen { > + bootargs = "console=ttySAC2,115200n8 root=/dev/ram0 ramdisk=16384 initrd=0x42000000,16M init=/linuxrc"; Having ramdisk bootargs like these in the upstream dts doesn't make much sense. Configure your bootloader to pass them in instead. You might want to specify the console through chosen instead, there's been recent support added for that. > + > + memory@40000000 { > + device_type = "memory"; > + reg = <0x40000000 0xC0000000>; > + }; > + > + mmc@15740000 { > + status = "okay"; > + num-slots = <1>; > + broken-cd; > + caps2-mmc-hs200-1_8v; > + supports-highspeed; > + non-removable; > + card-detect-delay = <200>; > + clock-frequency = <800000000>; > + 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_clk &sd0_cmd &sd0_rdqs &sd0_bus1 &sd0_bus4 &sd0_bus8>; > + bus-width = <8>; > + > + slot@0 { > + reg = <0>; > + bus-width = <8>; > + }; I thought the use of slot was deprecated. Why do you have it here? Also, as mentioned by others elsewhere, please use references instead of duplicating the structure here. -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 12/14] arm64: dts: add Exynos7 based Espresso board dts file @ 2014-08-28 4:00 ` Olof Johansson 0 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 4:00 UTC (permalink / raw) To: linux-arm-kernel Hi, On Wed, Aug 27, 2014 at 03:14:19PM +0530, Naveen Krishna Chatradhi wrote: > This patch adds initial dts file for the Espresso board > based on Exynos7 from Samsung. > > Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/boot/dts/Makefile | 1 + > arch/arm64/boot/dts/exynos7-espresso.dts | 69 ++++++++++++++++++++++++++++++ > 2 files changed, 70 insertions(+) > create mode 100644 arch/arm64/boot/dts/exynos7-espresso.dts > > diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile > index c52bdb0..d160de1 100644 > --- a/arch/arm64/boot/dts/Makefile > +++ b/arch/arm64/boot/dts/Makefile > @@ -1,5 +1,6 @@ > dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb > dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb > +dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb As mentioned on the dtsi patch, please create a subdirectory. > targets += dtbs > targets += $(dtb-y) > diff --git a/arch/arm64/boot/dts/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos7-espresso.dts > new file mode 100644 > index 0000000..e35e83c > --- /dev/null > +++ b/arch/arm64/boot/dts/exynos7-espresso.dts > @@ -0,0 +1,69 @@ > +/* > + * SAMSUNG Espresso board device tree source > + * > + * Copyright (c) 2014 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 <dt-bindings/gpio/gpio.h> > +#include "exynos7.dtsi" > + > +/ { > + model = "Samsung ESPRESSO board based on EXYNOS7"; > + compatible = "samsung,espresso", "samsung,exynos7"; > + > + chosen { > + bootargs = "console=ttySAC2,115200n8 root=/dev/ram0 ramdisk=16384 initrd=0x42000000,16M init=/linuxrc"; Having ramdisk bootargs like these in the upstream dts doesn't make much sense. Configure your bootloader to pass them in instead. You might want to specify the console through chosen instead, there's been recent support added for that. > + > + memory at 40000000 { > + device_type = "memory"; > + reg = <0x40000000 0xC0000000>; > + }; > + > + mmc at 15740000 { > + status = "okay"; > + num-slots = <1>; > + broken-cd; > + caps2-mmc-hs200-1_8v; > + supports-highspeed; > + non-removable; > + card-detect-delay = <200>; > + clock-frequency = <800000000>; > + 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_clk &sd0_cmd &sd0_rdqs &sd0_bus1 &sd0_bus4 &sd0_bus8>; > + bus-width = <8>; > + > + slot at 0 { > + reg = <0>; > + bus-width = <8>; > + }; I thought the use of slot was deprecated. Why do you have it here? Also, as mentioned by others elsewhere, please use references instead of duplicating the structure here. -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 12/14] arm64: dts: add Exynos7 based Espresso board dts file 2014-08-28 4:00 ` Olof Johansson @ 2014-08-29 5:51 ` Naveen Krishna Ch -1 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-08-29 5:51 UTC (permalink / raw) To: Olof Johansson Cc: Naveen Krishna Chatradhi, catalin.marinas, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Rob Herring Hello Olof, On 28 August 2014 09:30, Olof Johansson <olof@lixom.net> wrote: > Hi, > > On Wed, Aug 27, 2014 at 03:14:19PM +0530, Naveen Krishna Chatradhi wrote: >> This patch adds initial dts file for the Espresso board >> based on Exynos7 from Samsung. >> >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/Makefile | 1 + >> arch/arm64/boot/dts/exynos7-espresso.dts | 69 ++++++++++++++++++++++++++++++ >> 2 files changed, 70 insertions(+) >> create mode 100644 arch/arm64/boot/dts/exynos7-espresso.dts >> >> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile >> index c52bdb0..d160de1 100644 >> --- a/arch/arm64/boot/dts/Makefile >> +++ b/arch/arm64/boot/dts/Makefile >> @@ -1,5 +1,6 @@ >> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb >> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb >> +dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb > > As mentioned on the dtsi patch, please create a subdirectory. Sure, Will make it. > >> targets += dtbs >> targets += $(dtb-y) >> diff --git a/arch/arm64/boot/dts/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos7-espresso.dts >> new file mode 100644 >> index 0000000..e35e83c >> --- /dev/null >> +++ b/arch/arm64/boot/dts/exynos7-espresso.dts >> @@ -0,0 +1,69 @@ >> +/* >> + * SAMSUNG Espresso board device tree source >> + * >> + * Copyright (c) 2014 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 <dt-bindings/gpio/gpio.h> >> +#include "exynos7.dtsi" >> + >> +/ { >> + model = "Samsung ESPRESSO board based on EXYNOS7"; >> + compatible = "samsung,espresso", "samsung,exynos7"; >> + >> + chosen { >> + bootargs = "console=ttySAC2,115200n8 root=/dev/ram0 ramdisk=16384 initrd=0x42000000,16M init=/linuxrc"; > > Having ramdisk bootargs like these in the upstream dts doesn't make much > sense. Configure your bootloader to pass them in instead. Right, We have tested with ramdisk. So, Left it that way. Will remove this. > > You might want to specify the console through chosen instead, there's > been recent support added for that. > >> + >> + memory@40000000 { >> + device_type = "memory"; >> + reg = <0x40000000 0xC0000000>; >> + }; >> + >> + mmc@15740000 { >> + status = "okay"; >> + num-slots = <1>; >> + broken-cd; >> + caps2-mmc-hs200-1_8v; >> + supports-highspeed; >> + non-removable; >> + card-detect-delay = <200>; >> + clock-frequency = <800000000>; >> + 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_clk &sd0_cmd &sd0_rdqs &sd0_bus1 &sd0_bus4 &sd0_bus8>; >> + bus-width = <8>; >> + >> + slot@0 { >> + reg = <0>; >> + bus-width = <8>; >> + }; > > I thought the use of slot was deprecated. Why do you have it here? > > Also, as mentioned by others elsewhere, please use references instead > of duplicating the structure here. Sure, will rebase with the references. > > > -Olof Thanks for the review. -- Thanks & Regards, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 12/14] arm64: dts: add Exynos7 based Espresso board dts file @ 2014-08-29 5:51 ` Naveen Krishna Ch 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-08-29 5:51 UTC (permalink / raw) To: linux-arm-kernel Hello Olof, On 28 August 2014 09:30, Olof Johansson <olof@lixom.net> wrote: > Hi, > > On Wed, Aug 27, 2014 at 03:14:19PM +0530, Naveen Krishna Chatradhi wrote: >> This patch adds initial dts file for the Espresso board >> based on Exynos7 from Samsung. >> >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/boot/dts/Makefile | 1 + >> arch/arm64/boot/dts/exynos7-espresso.dts | 69 ++++++++++++++++++++++++++++++ >> 2 files changed, 70 insertions(+) >> create mode 100644 arch/arm64/boot/dts/exynos7-espresso.dts >> >> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile >> index c52bdb0..d160de1 100644 >> --- a/arch/arm64/boot/dts/Makefile >> +++ b/arch/arm64/boot/dts/Makefile >> @@ -1,5 +1,6 @@ >> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb >> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb >> +dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb > > As mentioned on the dtsi patch, please create a subdirectory. Sure, Will make it. > >> targets += dtbs >> targets += $(dtb-y) >> diff --git a/arch/arm64/boot/dts/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos7-espresso.dts >> new file mode 100644 >> index 0000000..e35e83c >> --- /dev/null >> +++ b/arch/arm64/boot/dts/exynos7-espresso.dts >> @@ -0,0 +1,69 @@ >> +/* >> + * SAMSUNG Espresso board device tree source >> + * >> + * Copyright (c) 2014 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 <dt-bindings/gpio/gpio.h> >> +#include "exynos7.dtsi" >> + >> +/ { >> + model = "Samsung ESPRESSO board based on EXYNOS7"; >> + compatible = "samsung,espresso", "samsung,exynos7"; >> + >> + chosen { >> + bootargs = "console=ttySAC2,115200n8 root=/dev/ram0 ramdisk=16384 initrd=0x42000000,16M init=/linuxrc"; > > Having ramdisk bootargs like these in the upstream dts doesn't make much > sense. Configure your bootloader to pass them in instead. Right, We have tested with ramdisk. So, Left it that way. Will remove this. > > You might want to specify the console through chosen instead, there's > been recent support added for that. > >> + >> + memory at 40000000 { >> + device_type = "memory"; >> + reg = <0x40000000 0xC0000000>; >> + }; >> + >> + mmc at 15740000 { >> + status = "okay"; >> + num-slots = <1>; >> + broken-cd; >> + caps2-mmc-hs200-1_8v; >> + supports-highspeed; >> + non-removable; >> + card-detect-delay = <200>; >> + clock-frequency = <800000000>; >> + 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_clk &sd0_cmd &sd0_rdqs &sd0_bus1 &sd0_bus4 &sd0_bus8>; >> + bus-width = <8>; >> + >> + slot at 0 { >> + reg = <0>; >> + bus-width = <8>; >> + }; > > I thought the use of slot was deprecated. Why do you have it here? > > Also, as mentioned by others elsewhere, please use references instead > of duplicating the structure here. Sure, will rebase with the references. > > > -Olof Thanks for the review. -- Thanks & Regards, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-27 9:44 ` Naveen Krishna Chatradhi -1 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Chatradhi @ 2014-08-27 9:44 UTC (permalink / raw) To: catalin.marinas Cc: naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Alim Akhtar, Rob Herring From: Alim Akhtar <alim.akhtar@samsung.com> This patch adds the necessary Kconfig entries to enable support for the ARMv8 based Exynos7 SoC. Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Cc: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/Kconfig | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index fd4e81a..d555558 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -134,6 +134,23 @@ source "kernel/Kconfig.freezer" menu "Platform selection" +config ARCH_EXYNOS7 + bool "ARMv8 based SAMSUNG EXYNOS7" + select HAVE_S3C2410_WATCHDOG if WATCHDOG + select CLKSRC_OF + select COMMON_CLK_SAMSUNG + select GPIOLIB + select PINCTRL + select PINCTRL_EXYNOS + select RTC_CLASS + select HAVE_S3C_RTC + select GENERIC_GPIO + select ARCH_REQUIRE_GPIOLIB + select HAVE_CLK + select HAVE_SMP + help + This enables support for SAMSUNG exynos7 SoC family + config ARCH_VEXPRESS bool "ARMv8 software model (Versatile Express)" select ARCH_REQUIRE_GPIOLIB -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support @ 2014-08-27 9:44 ` Naveen Krishna Chatradhi 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Chatradhi @ 2014-08-27 9:44 UTC (permalink / raw) To: linux-arm-kernel From: Alim Akhtar <alim.akhtar@samsung.com> This patch adds the necessary Kconfig entries to enable support for the ARMv8 based Exynos7 SoC. Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Cc: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/Kconfig | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index fd4e81a..d555558 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -134,6 +134,23 @@ source "kernel/Kconfig.freezer" menu "Platform selection" +config ARCH_EXYNOS7 + bool "ARMv8 based SAMSUNG EXYNOS7" + select HAVE_S3C2410_WATCHDOG if WATCHDOG + select CLKSRC_OF + select COMMON_CLK_SAMSUNG + select GPIOLIB + select PINCTRL + select PINCTRL_EXYNOS + select RTC_CLASS + select HAVE_S3C_RTC + select GENERIC_GPIO + select ARCH_REQUIRE_GPIOLIB + select HAVE_CLK + select HAVE_SMP + help + This enables support for SAMSUNG exynos7 SoC family + config ARCH_VEXPRESS bool "ARMv8 software model (Versatile Express)" select ARCH_REQUIRE_GPIOLIB -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-27 11:09 ` Mark Rutland -1 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-27 11:09 UTC (permalink / raw) To: Naveen Krishna Chatradhi Cc: Catalin Marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Alim Akhtar, Rob Herring Hi, On Wed, Aug 27, 2014 at 10:44:20AM +0100, Naveen Krishna Chatradhi wrote: > From: Alim Akhtar <alim.akhtar@samsung.com> > > This patch adds the necessary Kconfig entries to enable > support for the ARMv8 based Exynos7 SoC. > > Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> > Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/Kconfig | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index fd4e81a..d555558 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -134,6 +134,23 @@ source "kernel/Kconfig.freezer" > > menu "Platform selection" > > +config ARCH_EXYNOS7 > + bool "ARMv8 based SAMSUNG EXYNOS7" > + select HAVE_S3C2410_WATCHDOG if WATCHDOG > + select CLKSRC_OF This seems to be implied by ARM_ARCH_TIMER in the core arm64 Kconfig, so I'm not sure this is necessary. > + select COMMON_CLK_SAMSUNG > + select GPIOLIB You select ARCH_REQUIRE_GPIOLIB below, so is this necessary? > + select PINCTRL > + select PINCTRL_EXYNOS > + select RTC_CLASS > + select HAVE_S3C_RTC > + select GENERIC_GPIO > + select ARCH_REQUIRE_GPIOLIB > + select HAVE_CLK Isn't this selected already through the core arm64 Kconfig? It looks like we have COMMON_CLK, which selects CLKDEV_LOOKUP, which selects HAVE_CLK. > + select HAVE_SMP I may have missed something, but I didn't see any SMP support in this series. Thanks, Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support @ 2014-08-27 11:09 ` Mark Rutland 0 siblings, 0 replies; 84+ messages in thread From: Mark Rutland @ 2014-08-27 11:09 UTC (permalink / raw) To: linux-arm-kernel Hi, On Wed, Aug 27, 2014 at 10:44:20AM +0100, Naveen Krishna Chatradhi wrote: > From: Alim Akhtar <alim.akhtar@samsung.com> > > This patch adds the necessary Kconfig entries to enable > support for the ARMv8 based Exynos7 SoC. > > Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> > Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> > Cc: Rob Herring <robh@kernel.org> > Cc: Catalin Marinas <catalin.marinas@arm.com> > --- > arch/arm64/Kconfig | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index fd4e81a..d555558 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -134,6 +134,23 @@ source "kernel/Kconfig.freezer" > > menu "Platform selection" > > +config ARCH_EXYNOS7 > + bool "ARMv8 based SAMSUNG EXYNOS7" > + select HAVE_S3C2410_WATCHDOG if WATCHDOG > + select CLKSRC_OF This seems to be implied by ARM_ARCH_TIMER in the core arm64 Kconfig, so I'm not sure this is necessary. > + select COMMON_CLK_SAMSUNG > + select GPIOLIB You select ARCH_REQUIRE_GPIOLIB below, so is this necessary? > + select PINCTRL > + select PINCTRL_EXYNOS > + select RTC_CLASS > + select HAVE_S3C_RTC > + select GENERIC_GPIO > + select ARCH_REQUIRE_GPIOLIB > + select HAVE_CLK Isn't this selected already through the core arm64 Kconfig? It looks like we have COMMON_CLK, which selects CLKDEV_LOOKUP, which selects HAVE_CLK. > + select HAVE_SMP I may have missed something, but I didn't see any SMP support in this series. Thanks, Mark. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support 2014-08-27 11:09 ` Mark Rutland @ 2014-08-27 14:50 ` Catalin Marinas -1 siblings, 0 replies; 84+ messages in thread From: Catalin Marinas @ 2014-08-27 14:50 UTC (permalink / raw) To: Mark Rutland Cc: Naveen Krishna Chatradhi, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Alim Akhtar, Rob Herring On Wed, Aug 27, 2014 at 12:09:28PM +0100, Mark Rutland wrote: > On Wed, Aug 27, 2014 at 10:44:20AM +0100, Naveen Krishna Chatradhi wrote: > > + select HAVE_SMP > > I may have missed something, but I didn't see any SMP support in this > series. We don't even have HAVE_SMP defined for arm64 (just SMP, which is on in defconfig). In theory we don't need any specific SMP support for a new SoC as long as it uses a standard booting protocol (e.g. PSCI). But for whatever reason, I only received about four patches in this series, so can't see the rest. -- Catalin ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support @ 2014-08-27 14:50 ` Catalin Marinas 0 siblings, 0 replies; 84+ messages in thread From: Catalin Marinas @ 2014-08-27 14:50 UTC (permalink / raw) To: linux-arm-kernel On Wed, Aug 27, 2014 at 12:09:28PM +0100, Mark Rutland wrote: > On Wed, Aug 27, 2014 at 10:44:20AM +0100, Naveen Krishna Chatradhi wrote: > > + select HAVE_SMP > > I may have missed something, but I didn't see any SMP support in this > series. We don't even have HAVE_SMP defined for arm64 (just SMP, which is on in defconfig). In theory we don't need any specific SMP support for a new SoC as long as it uses a standard booting protocol (e.g. PSCI). But for whatever reason, I only received about four patches in this series, so can't see the rest. -- Catalin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support 2014-08-27 14:50 ` Catalin Marinas @ 2014-08-28 4:05 ` Olof Johansson -1 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 4:05 UTC (permalink / raw) To: Catalin Marinas Cc: Mark Rutland, Naveen Krishna Chatradhi, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Alim Akhtar, Rob Herring On Wed, Aug 27, 2014 at 03:50:21PM +0100, Catalin Marinas wrote: > On Wed, Aug 27, 2014 at 12:09:28PM +0100, Mark Rutland wrote: > > On Wed, Aug 27, 2014 at 10:44:20AM +0100, Naveen Krishna Chatradhi wrote: > > > + select HAVE_SMP > > > > I may have missed something, but I didn't see any SMP support in this > > series. > > We don't even have HAVE_SMP defined for arm64 (just SMP, which is on in > defconfig). > > In theory we don't need any specific SMP support for a new SoC as long > as it uses a standard booting protocol (e.g. PSCI). But for whatever > reason, I only received about four patches in this series, so can't see > the rest. Seems like about 9 of them made it to the list for me. -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support @ 2014-08-28 4:05 ` Olof Johansson 0 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 4:05 UTC (permalink / raw) To: linux-arm-kernel On Wed, Aug 27, 2014 at 03:50:21PM +0100, Catalin Marinas wrote: > On Wed, Aug 27, 2014 at 12:09:28PM +0100, Mark Rutland wrote: > > On Wed, Aug 27, 2014 at 10:44:20AM +0100, Naveen Krishna Chatradhi wrote: > > > + select HAVE_SMP > > > > I may have missed something, but I didn't see any SMP support in this > > series. > > We don't even have HAVE_SMP defined for arm64 (just SMP, which is on in > defconfig). > > In theory we don't need any specific SMP support for a new SoC as long > as it uses a standard booting protocol (e.g. PSCI). But for whatever > reason, I only received about four patches in this series, so can't see > the rest. Seems like about 9 of them made it to the list for me. -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support 2014-08-27 11:09 ` Mark Rutland @ 2014-09-03 8:14 ` Naveen Krishna Ch -1 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-09-03 8:14 UTC (permalink / raw) To: Mark Rutland Cc: Naveen Krishna Chatradhi, Catalin Marinas, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs, Alim Akhtar, Rob Herring Hi Mark, On 27 August 2014 16:39, Mark Rutland <mark.rutland@arm.com> wrote: > Hi, > > On Wed, Aug 27, 2014 at 10:44:20AM +0100, Naveen Krishna Chatradhi wrote: >> From: Alim Akhtar <alim.akhtar@samsung.com> >> >> This patch adds the necessary Kconfig entries to enable >> support for the ARMv8 based Exynos7 SoC. >> >> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/Kconfig | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index fd4e81a..d555558 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -134,6 +134,23 @@ source "kernel/Kconfig.freezer" >> >> menu "Platform selection" >> >> +config ARCH_EXYNOS7 >> + bool "ARMv8 based SAMSUNG EXYNOS7" >> + select HAVE_S3C2410_WATCHDOG if WATCHDOG >> + select CLKSRC_OF > > This seems to be implied by ARM_ARCH_TIMER in the core arm64 Kconfig, so > I'm not sure this is necessary. Ok. > >> + select COMMON_CLK_SAMSUNG >> + select GPIOLIB > > You select ARCH_REQUIRE_GPIOLIB below, so is this necessary? Yes, this is not required. Will remove. > >> + select PINCTRL >> + select PINCTRL_EXYNOS >> + select RTC_CLASS >> + select HAVE_S3C_RTC >> + select GENERIC_GPIO >> + select ARCH_REQUIRE_GPIOLIB >> + select HAVE_CLK > > Isn't this selected already through the core arm64 Kconfig? > > It looks like we have COMMON_CLK, which selects CLKDEV_LOOKUP, which > selects HAVE_CLK. Ok. > >> + select HAVE_SMP > > I may have missed something, but I didn't see any SMP support in this > series. As Catalin suggested, will remove this. > > Thanks, > Mark. Thanks for your comments. -- Shine bright, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support @ 2014-09-03 8:14 ` Naveen Krishna Ch 0 siblings, 0 replies; 84+ messages in thread From: Naveen Krishna Ch @ 2014-09-03 8:14 UTC (permalink / raw) To: linux-arm-kernel Hi Mark, On 27 August 2014 16:39, Mark Rutland <mark.rutland@arm.com> wrote: > Hi, > > On Wed, Aug 27, 2014 at 10:44:20AM +0100, Naveen Krishna Chatradhi wrote: >> From: Alim Akhtar <alim.akhtar@samsung.com> >> >> This patch adds the necessary Kconfig entries to enable >> support for the ARMv8 based Exynos7 SoC. >> >> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> >> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> --- >> arch/arm64/Kconfig | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index fd4e81a..d555558 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -134,6 +134,23 @@ source "kernel/Kconfig.freezer" >> >> menu "Platform selection" >> >> +config ARCH_EXYNOS7 >> + bool "ARMv8 based SAMSUNG EXYNOS7" >> + select HAVE_S3C2410_WATCHDOG if WATCHDOG >> + select CLKSRC_OF > > This seems to be implied by ARM_ARCH_TIMER in the core arm64 Kconfig, so > I'm not sure this is necessary. Ok. > >> + select COMMON_CLK_SAMSUNG >> + select GPIOLIB > > You select ARCH_REQUIRE_GPIOLIB below, so is this necessary? Yes, this is not required. Will remove. > >> + select PINCTRL >> + select PINCTRL_EXYNOS >> + select RTC_CLASS >> + select HAVE_S3C_RTC >> + select GENERIC_GPIO >> + select ARCH_REQUIRE_GPIOLIB >> + select HAVE_CLK > > Isn't this selected already through the core arm64 Kconfig? > > It looks like we have COMMON_CLK, which selects CLKDEV_LOOKUP, which > selects HAVE_CLK. Ok. > >> + select HAVE_SMP > > I may have missed something, but I didn't see any SMP support in this > series. As Catalin suggested, will remove this. > > Thanks, > Mark. Thanks for your comments. -- Shine bright, (: Nav :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-27 11:34 ` Tomasz Figa -1 siblings, 0 replies; 84+ messages in thread From: Tomasz Figa @ 2014-08-27 11:34 UTC (permalink / raw) To: Naveen Krishna Chatradhi, catalin.marinas Cc: naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs Hi Naveen, On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: > This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. > Exynos7 is a System-On-Chip (SoC) that is based on 64-bit > ARMv8 RISC processor. A general issue with this series is that it introduces a very generic name for a very specific single SoC. We remember exactly the same cases for Exynos4 (original name used for Exynos5250) and Exynos5 (Exynos5250) and we should have learned that it is better to use a specific name first and only then try to make things common if it turns out to be appropriate. Best regards, Tomasz ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC @ 2014-08-27 11:34 ` Tomasz Figa 0 siblings, 0 replies; 84+ messages in thread From: Tomasz Figa @ 2014-08-27 11:34 UTC (permalink / raw) To: linux-arm-kernel Hi Naveen, On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: > This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. > Exynos7 is a System-On-Chip (SoC) that is based on 64-bit > ARMv8 RISC processor. A general issue with this series is that it introduces a very generic name for a very specific single SoC. We remember exactly the same cases for Exynos4 (original name used for Exynos5250) and Exynos5 (Exynos5250) and we should have learned that it is better to use a specific name first and only then try to make things common if it turns out to be appropriate. Best regards, Tomasz ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC 2014-08-27 11:34 ` Tomasz Figa @ 2014-09-13 10:57 ` Tomasz Figa -1 siblings, 0 replies; 84+ messages in thread From: Tomasz Figa @ 2014-09-13 10:57 UTC (permalink / raw) To: Naveen Krishna Chatradhi, catalin.marinas Cc: naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs On 27.08.2014 13:34, Tomasz Figa wrote: > Hi Naveen, > > On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: >> This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. >> Exynos7 is a System-On-Chip (SoC) that is based on 64-bit >> ARMv8 RISC processor. > > A general issue with this series is that it introduces a very generic > name for a very specific single SoC. We remember exactly the same cases > for Exynos4 (original name used for Exynos5250) and Exynos5 (Exynos5250) > and we should have learned that it is better to use a specific name > first and only then try to make things common if it turns out to be > appropriate. Any comments on this? ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC @ 2014-09-13 10:57 ` Tomasz Figa 0 siblings, 0 replies; 84+ messages in thread From: Tomasz Figa @ 2014-09-13 10:57 UTC (permalink / raw) To: linux-arm-kernel On 27.08.2014 13:34, Tomasz Figa wrote: > Hi Naveen, > > On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: >> This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. >> Exynos7 is a System-On-Chip (SoC) that is based on 64-bit >> ARMv8 RISC processor. > > A general issue with this series is that it introduces a very generic > name for a very specific single SoC. We remember exactly the same cases > for Exynos4 (original name used for Exynos5250) and Exynos5 (Exynos5250) > and we should have learned that it is better to use a specific name > first and only then try to make things common if it turns out to be > appropriate. Any comments on this? ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC 2014-09-13 10:57 ` Tomasz Figa @ 2014-09-14 13:45 ` Thomas Abraham -1 siblings, 0 replies; 84+ messages in thread From: Thomas Abraham @ 2014-09-14 13:45 UTC (permalink / raw) To: Tomasz Figa Cc: Naveen Krishna Chatradhi, catalin.marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs Hi Tomasz, On Sat, Sep 13, 2014 at 4:27 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote: > On 27.08.2014 13:34, Tomasz Figa wrote: >> Hi Naveen, >> >> On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: >>> This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. >>> Exynos7 is a System-On-Chip (SoC) that is based on 64-bit >>> ARMv8 RISC processor. >> >> A general issue with this series is that it introduces a very generic >> name for a very specific single SoC. We remember exactly the same cases >> for Exynos4 (original name used for Exynos5250) and Exynos5 (Exynos5250) >> and we should have learned that it is better to use a specific name >> first and only then try to make things common if it turns out to be >> appropriate. > > Any comments on this? The name of the SoC is Exynos7 and so all these patches are using Exynos7 in dt compatible string and file names. If there are any variants of Exynos7 SoC in future, support those variants will be based on what is already merged for Exynos7 SoC. There is no specific generalization targeted in this series by using Exynos7 name. Thanks, Thomas. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC @ 2014-09-14 13:45 ` Thomas Abraham 0 siblings, 0 replies; 84+ messages in thread From: Thomas Abraham @ 2014-09-14 13:45 UTC (permalink / raw) To: linux-arm-kernel Hi Tomasz, On Sat, Sep 13, 2014 at 4:27 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote: > On 27.08.2014 13:34, Tomasz Figa wrote: >> Hi Naveen, >> >> On 27.08.2014 11:44, Naveen Krishna Chatradhi wrote: >>> This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. >>> Exynos7 is a System-On-Chip (SoC) that is based on 64-bit >>> ARMv8 RISC processor. >> >> A general issue with this series is that it introduces a very generic >> name for a very specific single SoC. We remember exactly the same cases >> for Exynos4 (original name used for Exynos5250) and Exynos5 (Exynos5250) >> and we should have learned that it is better to use a specific name >> first and only then try to make things common if it turns out to be >> appropriate. > > Any comments on this? The name of the SoC is Exynos7 and so all these patches are using Exynos7 in dt compatible string and file names. If there are any variants of Exynos7 SoC in future, support those variants will be based on what is already merged for Exynos7 SoC. There is no specific generalization targeted in this series by using Exynos7 name. Thanks, Thomas. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC 2014-08-27 9:44 ` Naveen Krishna Chatradhi @ 2014-08-28 3:47 ` Olof Johansson -1 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 3:47 UTC (permalink / raw) To: Naveen Krishna Chatradhi Cc: catalin.marinas, naveenkrishna.ch, linux-arm-kernel, linux-samsung-soc, devicetree, cpgs Naveen, On Wed, Aug 27, 2014 at 03:14:16PM +0530, Naveen Krishna Chatradhi wrote: > This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. > Exynos7 is a System-On-Chip (SoC) that is based on 64-bit > ARMv8 RISC processor. Your emails haven't threaded properly, so the series of patches are not recognized as comments to the envelope (00/14) email. It makes it harder to review them in order, and some mailers might not group them well. > We tested these patches with the > "arm64: dts: add <dt-bindings/> symlink" change posted @ > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224629.html That means that these patches can't be picked up until a permanent solution for that has gone in. -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
* [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC @ 2014-08-28 3:47 ` Olof Johansson 0 siblings, 0 replies; 84+ messages in thread From: Olof Johansson @ 2014-08-28 3:47 UTC (permalink / raw) To: linux-arm-kernel Naveen, On Wed, Aug 27, 2014 at 03:14:16PM +0530, Naveen Krishna Chatradhi wrote: > This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. > Exynos7 is a System-On-Chip (SoC) that is based on 64-bit > ARMv8 RISC processor. Your emails haven't threaded properly, so the series of patches are not recognized as comments to the envelope (00/14) email. It makes it harder to review them in order, and some mailers might not group them well. > We tested these patches with the > "arm64: dts: add <dt-bindings/> symlink" change posted @ > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224629.html That means that these patches can't be picked up until a permanent solution for that has gone in. -Olof ^ permalink raw reply [flat|nested] 84+ messages in thread
end of thread, other threads:[~2014-09-14 13:45 UTC | newest] Thread overview: 84+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-08-27 9:44 [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC Naveen Krishna Chatradhi 2014-08-27 9:44 ` Naveen Krishna Chatradhi 2014-08-27 9:44 ` [PATCH 10/14] arm64: dts: add pinctrl support to EXYNOS7 Naveen Krishna Chatradhi 2014-08-27 9:44 ` Naveen Krishna Chatradhi 2014-08-27 11:14 ` Tomasz Figa 2014-08-27 11:14 ` Tomasz Figa 2014-08-29 5:46 ` Naveen Krishna Ch 2014-08-29 5:46 ` Naveen Krishna Ch 2014-08-27 9:44 ` [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 Naveen Krishna Chatradhi 2014-08-27 9:44 ` Naveen Krishna Chatradhi 2014-08-27 10:42 ` Mark Rutland 2014-08-27 10:42 ` Mark Rutland 2014-08-27 14:54 ` Catalin Marinas 2014-08-27 14:54 ` Catalin Marinas 2014-09-03 7:48 ` Naveen Krishna Ch 2014-09-03 7:48 ` Naveen Krishna Ch 2014-08-27 11:30 ` Tomasz Figa 2014-08-27 11:30 ` Tomasz Figa 2014-09-03 7:55 ` Naveen Krishna Ch 2014-09-03 7:55 ` Naveen Krishna Ch 2014-08-28 3:56 ` Olof Johansson 2014-08-28 3:56 ` Olof Johansson 2014-08-28 8:35 ` Marc Zyngier 2014-08-28 8:35 ` Marc Zyngier 2014-08-28 9:48 ` Mark Rutland 2014-08-28 9:48 ` Mark Rutland 2014-08-28 16:28 ` Olof Johansson 2014-08-28 16:28 ` Olof Johansson 2014-08-28 17:03 ` Mark Rutland 2014-08-28 17:03 ` Mark Rutland 2014-08-28 17:19 ` Olof Johansson 2014-08-28 17:19 ` Olof Johansson 2014-08-28 17:39 ` Mark Rutland 2014-08-28 17:39 ` Mark Rutland 2014-08-28 17:47 ` Geert Uytterhoeven 2014-08-28 17:47 ` Geert Uytterhoeven 2014-08-28 18:17 ` Mark Rutland 2014-08-28 18:17 ` Mark Rutland 2014-08-28 17:54 ` Rob Herring 2014-08-28 17:54 ` Rob Herring 2014-08-28 22:23 ` Olof Johansson 2014-08-28 22:23 ` Olof Johansson 2014-08-28 23:30 ` Simon Horman 2014-08-28 23:30 ` Simon Horman 2014-08-28 17:27 ` Marc Zyngier 2014-08-28 17:27 ` Marc Zyngier 2014-08-28 17:30 ` Mark Rutland 2014-08-28 17:30 ` Mark Rutland 2014-08-28 17:37 ` Marc Zyngier 2014-08-28 17:37 ` Marc Zyngier 2014-08-28 17:45 ` Mark Rutland 2014-08-28 17:45 ` Mark Rutland [not found] ` <53FF6668.4080502-5wv7dgnIgG8@public.gmane.org> 2014-08-28 17:33 ` Rob Herring 2014-08-28 17:33 ` Rob Herring 2014-08-28 17:43 ` Mark Rutland 2014-08-28 17:43 ` Mark Rutland 2014-09-03 8:05 ` Naveen Krishna Ch 2014-09-03 8:05 ` Naveen Krishna Ch 2014-08-27 9:44 ` [PATCH 12/14] arm64: dts: add Exynos7 based Espresso board dts file Naveen Krishna Chatradhi 2014-08-27 9:44 ` Naveen Krishna Chatradhi 2014-08-27 11:32 ` Tomasz Figa 2014-08-27 11:32 ` Tomasz Figa 2014-08-28 4:00 ` Olof Johansson 2014-08-28 4:00 ` Olof Johansson 2014-08-29 5:51 ` Naveen Krishna Ch 2014-08-29 5:51 ` Naveen Krishna Ch 2014-08-27 9:44 ` [PATCH 13/14] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support Naveen Krishna Chatradhi 2014-08-27 9:44 ` Naveen Krishna Chatradhi 2014-08-27 11:09 ` Mark Rutland 2014-08-27 11:09 ` Mark Rutland 2014-08-27 14:50 ` Catalin Marinas 2014-08-27 14:50 ` Catalin Marinas 2014-08-28 4:05 ` Olof Johansson 2014-08-28 4:05 ` Olof Johansson 2014-09-03 8:14 ` Naveen Krishna Ch 2014-09-03 8:14 ` Naveen Krishna Ch 2014-08-27 11:34 ` [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC Tomasz Figa 2014-08-27 11:34 ` Tomasz Figa 2014-09-13 10:57 ` Tomasz Figa 2014-09-13 10:57 ` Tomasz Figa 2014-09-14 13:45 ` Thomas Abraham 2014-09-14 13:45 ` Thomas Abraham 2014-08-28 3:47 ` Olof Johansson 2014-08-28 3:47 ` Olof Johansson
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.