| Message ID | 1391577375-17625-3-git-send-email-rahul.sharma@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Rahul, Pankaj, Arun, [adding linux-arm-kernel, devicetree MLs and DT people on Cc] I think it's good time to stop accepting DTS files like this and force new ones to use the proper structure with soc node, labels for every node and node references. In case of previous Exynos 5 SoCs I hadn't complained, because they shared a lot of data with already existing exynos5.dtsi, but since Exynos5260 is completely different, I'd say it should be converted to the new layout. As an example you can look at arch/arm/boot/dts/s3c64xx.dtsi and files that include it or, for more complete structures, DTS of other platforms, such as imx6*. Btw. Please remember that linux-samsung-soc mailing list is just a convenient utility for reviewers of Samsung-specific patches to have all of them in one place. Sending patches to it alone is not enough - a general kernel ML list needs to be CCed as well, in this case linux-arm-kernel. Also, please see my comments inline, for review comments unrelated to the issue described above. On 05.02.2014 06:16, Rahul Sharma wrote: > The patch adds the dts files for exynos5260. > > Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com> > Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com> > Signed-off-by: Arun Kumar K <arun.kk@samsung.com> > --- > arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572 +++++++++++++++++++++++++++++ > arch/arm/boot/dts/exynos5260.dtsi | 317 ++++++++++++++++ > 2 files changed, 889 insertions(+) > create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi > create mode 100644 arch/arm/boot/dts/exynos5260.dtsi > > diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi > new file mode 100644 > index 0000000..3f2c5c4 > --- /dev/null > +++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi > @@ -0,0 +1,572 @@ > +/* > + * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source > + * > + * Copyright (c) 2013 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as device > + * tree nodes are listed in this file. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > +*/ > + > +/ { > + pinctrl@11600000 { [snip] > + spi0_bus: spi0-bus { > + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", "gpa2-3"; What is the reason for SPI0 to have 4 pins, while SPI1 has just 3? > + samsung,pin-function = <2>; > + samsung,pin-pud = <3>; > + samsung,pin-drv = <0>; > + }; [snip] > diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi > new file mode 100644 > index 0000000..32a95c7 > --- /dev/null > +++ b/arch/arm/boot/dts/exynos5260.dtsi > @@ -0,0 +1,317 @@ > +/* > + * SAMSUNG EXYNOS5260 SoC device tree source > + * > + * Copyright (c) 2013 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > +*/ > + > +#include "skeleton.dtsi" > +#include "exynos5260-pinctrl.dtsi" > + > +#include <dt-bindings/clk/exynos5260-clk.h> > + > +/ { > + compatible = "samsung,exynos5260"; > + interrupt-parent = <&gic>; > + > + aliases { > + pinctrl0 = &pinctrl_0; > + pinctrl1 = &pinctrl_1; > + pinctrl2 = &pinctrl_2; > + }; > + > + chipid@10000000 { > + compatible = "samsung,exynos4210-chipid"; > + reg = <0x10000000 0x100>; > + }; > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a15"; > + reg = <0>; nit: Please make this consistent with CPUs 10x below, by using hex here as well. > + cci-control-port = <&cci_control1>; > + }; nit: Please keep 1 blank line of spacing between nodes. > + cpu@1 { > + device_type = "cpu"; > + compatible = "arm,cortex-a15"; > + reg = <1>; > + cci-control-port = <&cci_control1>; > + }; > + cpu@100 { > + device_type = "cpu"; > + compatible = "arm,cortex-a7"; > + reg = <0x100>; > + cci-control-port = <&cci_control0>; > + }; > + cpu@101 { > + device_type = "cpu"; > + compatible = "arm,cortex-a7"; > + reg = <0x101>; > + cci-control-port = <&cci_control0>; > + }; > + cpu@102 { > + device_type = "cpu"; > + compatible = "arm,cortex-a7"; > + reg = <0x102>; > + cci-control-port = <&cci_control0>; > + }; > + cpu@103 { > + device_type = "cpu"; > + compatible = "arm,cortex-a7"; > + reg = <0x103>; > + cci-control-port = <&cci_control0>; > + }; > + }; > + > + cmus { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + I don't think there is a need to group these nodes under a parent node that doesn't give any additional information, especially when the CMUs are scattered trough the whole address space, while we'd like to keep the nodes ordered by their addresses, as most platforms do. > + cmu_top: clock-controller@10010000 { > + compatible = "exynos5260-cmu-top", "samsung,exynos5260-clock"; I don't think that having the "samsung,exynos5260-clock" compatible string for every CMU is appropriate here, because there is no way to automatically recognize which CMU it is. Since every CMU instance is different, they need to have different compatible strings. > + reg = <0x10010000 0x10000>; > + #clock-cells = <1>; > + }; [snip] > + mct@100B0000 { > + compatible = "samsung,exynos4210-mct"; > + reg = <0x100B0000 0x1000>; > + interrupt-controller; > + #interrups-cells = <1>; MCT is not an interrupt controller, so the 2 properties above are incorrect. > + interrupt-parent = <&mct_map>; > + interrupts = <0>, <1>, <2>, <3>, > + <4>, <5>, <6>, <7>, > + <8>, <9>, <10>, <11>; > + clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>; > + clock-names = "fin_pll", "mct"; > + > + mct_map: mct-map { > + #interrupt-cells = <1>; > + #address-cells = <0>; > + #size-cells = <0>; > + interrupt-map = <0 &gic 0 104 0>, > + <1 &gic 0 105 0>, > + <2 &gic 0 106 0>, > + <3 &gic 0 107 0>, > + <4 &gic 0 122 0>, > + <5 &gic 0 123 0>, > + <6 &gic 0 124 0>, > + <7 &gic 0 125 0>, > + <8 &gic 0 126 0>, > + <9 &gic 0 127 0>, > + <10 &gic 0 128 0>, > + <11 &gic 0 129 0>; > + }; There is no need for interrupt-map here, because all the interrupts are from GIC. > + }; [snip] > + mmc_0: mmc0@12140000 { > + compatible = "samsung,exynos5250-dw-mshc"; > + reg = <0x12140000 0x2000>; > + interrupts = <0 156 0>; > + #address-cells = <1>; > + #size-cells = <0>; > + clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top TOP_SCLK_MMC0>; > + clock-names = "biu", "ciu"; > + fifo-depth = <0x40>; nit: It might be more readable to use decimal 64 here. Best regards, Tomasz -- 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
Hi Tomasz, On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote: > Hi Rahul, Pankaj, Arun, > > [adding linux-arm-kernel, devicetree MLs and DT people on Cc] > > I think it's good time to stop accepting DTS files like this and force new > ones to use the proper structure with soc node, labels for every node and > node references. I am unable to find information on SoC node and grouping inside SoC node. Please share some pointers. > > In case of previous Exynos 5 SoCs I hadn't complained, because they shared a > lot of data with already existing exynos5.dtsi, but since Exynos5260 is > completely different, I'd say it should be converted to the new layout. > > As an example you can look at arch/arm/boot/dts/s3c64xx.dtsi and files that > include it or, for more complete structures, DTS of other platforms, such as > imx6*. > > Btw. Please remember that linux-samsung-soc mailing list is just a > convenient utility for reviewers of Samsung-specific patches to have all of > them in one place. Sending patches to it alone is not enough - a general > kernel ML list needs to be CCed as well, in this case linux-arm-kernel. > I will take care of this. > Also, please see my comments inline, for review comments unrelated to the > issue described above. > > > On 05.02.2014 06:16, Rahul Sharma wrote: >> >> The patch adds the dts files for exynos5260. >> >> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com> >> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com> >> Signed-off-by: Arun Kumar K <arun.kk@samsung.com> >> --- >> arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572 >> +++++++++++++++++++++++++++++ >> arch/arm/boot/dts/exynos5260.dtsi | 317 ++++++++++++++++ >> 2 files changed, 889 insertions(+) >> create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi >> create mode 100644 arch/arm/boot/dts/exynos5260.dtsi >> >> diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi >> b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi >> new file mode 100644 >> index 0000000..3f2c5c4 >> --- /dev/null >> +++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi >> @@ -0,0 +1,572 @@ >> +/* >> + * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source >> + * >> + * Copyright (c) 2013 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as >> device >> + * tree nodes are listed in this file. >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> +*/ >> + >> +/ { >> + pinctrl@11600000 { > > > [snip] > > >> + spi0_bus: spi0-bus { >> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", >> "gpa2-3"; > > > What is the reason for SPI0 to have 4 pins, while SPI1 has just 3? > I should align SPI1 with SPI0. > >> + samsung,pin-function = <2>; >> + samsung,pin-pud = <3>; >> + samsung,pin-drv = <0>; >> + }; > > > [snip] > > >> diff --git a/arch/arm/boot/dts/exynos5260.dtsi >> b/arch/arm/boot/dts/exynos5260.dtsi >> new file mode 100644 >> index 0000000..32a95c7 >> --- /dev/null >> +++ b/arch/arm/boot/dts/exynos5260.dtsi >> @@ -0,0 +1,317 @@ >> +/* >> + * SAMSUNG EXYNOS5260 SoC device tree source >> + * >> + * Copyright (c) 2013 Samsung Electronics Co., Ltd. >> + * http://www.samsung.com >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> +*/ >> + >> +#include "skeleton.dtsi" >> +#include "exynos5260-pinctrl.dtsi" >> + >> +#include <dt-bindings/clk/exynos5260-clk.h> >> + >> +/ { >> + compatible = "samsung,exynos5260"; >> + interrupt-parent = <&gic>; >> + >> + aliases { >> + pinctrl0 = &pinctrl_0; >> + pinctrl1 = &pinctrl_1; >> + pinctrl2 = &pinctrl_2; >> + }; >> + >> + chipid@10000000 { >> + compatible = "samsung,exynos4210-chipid"; >> + reg = <0x10000000 0x100>; >> + }; >> + >> + cpus { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + cpu@0 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a15"; >> + reg = <0>; > > > nit: Please make this consistent with CPUs 10x below, by using hex here as > well. > Done. > >> + cci-control-port = <&cci_control1>; >> + }; > > > nit: Please keep 1 blank line of spacing between nodes. > ok. > >> + cpu@1 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a15"; >> + reg = <1>; >> + cci-control-port = <&cci_control1>; >> + }; >> + cpu@100 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a7"; >> + reg = <0x100>; >> + cci-control-port = <&cci_control0>; >> + }; >> + cpu@101 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a7"; >> + reg = <0x101>; >> + cci-control-port = <&cci_control0>; >> + }; >> + cpu@102 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a7"; >> + reg = <0x102>; >> + cci-control-port = <&cci_control0>; >> + }; >> + cpu@103 { >> + device_type = "cpu"; >> + compatible = "arm,cortex-a7"; >> + reg = <0x103>; >> + cci-control-port = <&cci_control0>; >> + }; >> + }; >> + >> + cmus { >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges; >> + > > > I don't think there is a need to group these nodes under a parent node that > doesn't give any additional information, especially when the CMUs are > scattered trough the whole address space, while we'd like to keep the nodes > ordered by their addresses, as most platforms do. > This is exactly the same case as "cpus". I mean, "cpus" also doesn't provide any common information about child cpu nodes. This looks to me as a logical grouping and I have implemented same thing for cmu nodes. I am ok with removing this grouping Just want to understand the rational behind grouping cpus which seems similar to cmus. Similarly "soc" is just a logical entity used to group SoC elements which looks optional to me. What are we achieving with this? Please help me in understanding this better. > >> + cmu_top: clock-controller@10010000 { >> + compatible = "exynos5260-cmu-top", >> "samsung,exynos5260-clock"; > > > I don't think that having the "samsung,exynos5260-clock" compatible string > for every CMU is appropriate here, because there is no way to automatically > recognize which CMU it is. Since every CMU instance is different, they need > to have different compatible strings. > Changed. > >> + reg = <0x10010000 0x10000>; >> + #clock-cells = <1>; >> + }; > > > [snip] > > >> + mct@100B0000 { >> + compatible = "samsung,exynos4210-mct"; >> + reg = <0x100B0000 0x1000>; >> + interrupt-controller; >> + #interrups-cells = <1>; > > > MCT is not an interrupt controller, so the 2 properties above are incorrect. > Agree. I will change this. > >> + interrupt-parent = <&mct_map>; >> + interrupts = <0>, <1>, <2>, <3>, >> + <4>, <5>, <6>, <7>, >> + <8>, <9>, <10>, <11>; >> + clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>; >> + clock-names = "fin_pll", "mct"; >> + >> + mct_map: mct-map { >> + #interrupt-cells = <1>; >> + #address-cells = <0>; >> + #size-cells = <0>; >> + interrupt-map = <0 &gic 0 104 0>, >> + <1 &gic 0 105 0>, >> + <2 &gic 0 106 0>, >> + <3 &gic 0 107 0>, >> + <4 &gic 0 122 0>, >> + <5 &gic 0 123 0>, >> + <6 &gic 0 124 0>, >> + <7 &gic 0 125 0>, >> + <8 &gic 0 126 0>, >> + <9 &gic 0 127 0>, >> + <10 &gic 0 128 0>, >> + <11 &gic 0 129 0>; >> + }; > > > There is no need for interrupt-map here, because all the interrupts are from > GIC. > Done. Regards, Rahul Sharma. >> + }; > > > [snip] > > >> + mmc_0: mmc0@12140000 { >> + compatible = "samsung,exynos5250-dw-mshc"; >> + reg = <0x12140000 0x2000>; >> + interrupts = <0 156 0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top >> TOP_SCLK_MMC0>; >> + clock-names = "biu", "ciu"; >> + fifo-depth = <0x40>; > > > nit: It might be more readable to use decimal 64 here. > > Best regards, > Tomasz -- 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
Hi Rahul, On 11.02.2014 06:22, Rahul Sharma wrote: > Hi Tomasz, > > On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote: >> Hi Rahul, Pankaj, Arun, >> >> [adding linux-arm-kernel, devicetree MLs and DT people on Cc] >> >> I think it's good time to stop accepting DTS files like this and force new >> ones to use the proper structure with soc node, labels for every node and >> node references. > > I am unable to find information on SoC node and grouping inside SoC node. Please > share some pointers. Well, there is not much information needed about this. Basically all the devices built into the SoC should be listed under respective bus nodes or a single soc node, instead of root level. Such node should be a "simple-bus" and just group the components together to separate board-specific devices (which are still at root level) from SoC devices. Even though it might seem useless, it improves DT readability a bit and still most of the platforms use this approach, so for consistency, Exynos should use too. Just for reference, back in April 2013, in his review of S3C64xx DT series [1], Rob Herring requested that we don't submit any new device trees using flat approach and start using bus hierarchy. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html >> >>> + spi0_bus: spi0-bus { >>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", >>> "gpa2-3"; >> >> >> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3? >> > > I should align SPI1 with SPI0. > Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI, SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to the fact that the controller can only support one dedicated chip select and with direct GPIO control you can have more. What is the fourth pin here? >> >>> + cpu@1 { >>> + device_type = "cpu"; >>> + compatible = "arm,cortex-a15"; >>> + reg = <1>; >>> + cci-control-port = <&cci_control1>; >>> + }; >>> + cpu@100 { >>> + device_type = "cpu"; >>> + compatible = "arm,cortex-a7"; >>> + reg = <0x100>; >>> + cci-control-port = <&cci_control0>; >>> + }; >>> + cpu@101 { >>> + device_type = "cpu"; >>> + compatible = "arm,cortex-a7"; >>> + reg = <0x101>; >>> + cci-control-port = <&cci_control0>; >>> + }; >>> + cpu@102 { >>> + device_type = "cpu"; >>> + compatible = "arm,cortex-a7"; >>> + reg = <0x102>; >>> + cci-control-port = <&cci_control0>; >>> + }; >>> + cpu@103 { >>> + device_type = "cpu"; >>> + compatible = "arm,cortex-a7"; >>> + reg = <0x103>; >>> + cci-control-port = <&cci_control0>; >>> + }; >>> + }; >>> + >>> + cmus { >>> + #address-cells = <1>; >>> + #size-cells = <1>; >>> + ranges; >>> + >> >> >> I don't think there is a need to group these nodes under a parent node that >> doesn't give any additional information, especially when the CMUs are >> scattered trough the whole address space, while we'd like to keep the nodes >> ordered by their addresses, as most platforms do. >> > > This is exactly the same case as "cpus". I mean, "cpus" also doesn't provide > any common information about child cpu nodes. This looks to me as a logical > grouping and I have implemented same thing for cmu nodes. > I am ok with removing this grouping Just want to understand the rational behind > grouping cpus which seems similar to cmus. The "cpus" node is a defined standard node that should be present at root of device tree and include subnodes for all CPUs. This is a standard binding defined for low level code to be able to simply find nodes of all CPUs in the system - so they can expect that at /cpus node all the subnodes are subsequent CPUs. > Similarly "soc" is just a logical entity used to group SoC elements which looks > optional to me. What are we achieving with this? Please help me in understanding > this better. Also "soc" has a slightly wider meaning. It is a node grouping all nodes from a single address space - the node specifies #address-cells and #size-cells of this address space and all the devices under this "simple-bus" can be accessed using addresses in this format. In addition, it separates board-level devices from generic SoC devices. Now, in case of "cmus", the only purpose is to group all CMU nodes together and, while this improves readability a bit, it doesn't make the DT better express the hardware topology, because the CMUs in the hardware are in fact scattered through the whole address space, not under a contiguous block of it, as the grouping would suggest. Best regards, Tomasz -- 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
Thanks Tomasz, I will add these changes to v3. Regards, Rahul Sharma. On 11 February 2014 15:34, Tomasz Figa <tomasz.figa@gmail.com> wrote: > Hi Rahul, > > > On 11.02.2014 06:22, Rahul Sharma wrote: >> >> Hi Tomasz, >> >> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote: >>> >>> Hi Rahul, Pankaj, Arun, >>> >>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc] >>> >>> I think it's good time to stop accepting DTS files like this and force >>> new >>> ones to use the proper structure with soc node, labels for every node and >>> node references. >> >> >> I am unable to find information on SoC node and grouping inside SoC node. >> Please >> share some pointers. > > > Well, there is not much information needed about this. Basically all the > devices built into the SoC should be listed under respective bus nodes or a > single soc node, instead of root level. Such node should be a "simple-bus" > and just group the components together to separate board-specific devices > (which are still at root level) from SoC devices. > > Even though it might seem useless, it improves DT readability a bit and > still most of the platforms use this approach, so for consistency, Exynos > should use too. > > Just for reference, back in April 2013, in his review of S3C64xx DT series > [1], Rob Herring requested that we don't submit any new device trees using > flat approach and start using bus hierarchy. > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html > > >>> >>>> + spi0_bus: spi0-bus { >>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", >>>> "gpa2-3"; >>> >>> >>> >>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3? >>> >> >> I should align SPI1 with SPI0. >> > > Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI, > SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to > the fact that the controller can only support one dedicated chip select and > with direct GPIO control you can have more. > > What is the fourth pin here? > > >>> >>>> + cpu@1 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a15"; >>>> + reg = <1>; >>>> + cci-control-port = <&cci_control1>; >>>> + }; >>>> + cpu@100 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a7"; >>>> + reg = <0x100>; >>>> + cci-control-port = <&cci_control0>; >>>> + }; >>>> + cpu@101 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a7"; >>>> + reg = <0x101>; >>>> + cci-control-port = <&cci_control0>; >>>> + }; >>>> + cpu@102 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a7"; >>>> + reg = <0x102>; >>>> + cci-control-port = <&cci_control0>; >>>> + }; >>>> + cpu@103 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a7"; >>>> + reg = <0x103>; >>>> + cci-control-port = <&cci_control0>; >>>> + }; >>>> + }; >>>> + >>>> + cmus { >>>> + #address-cells = <1>; >>>> + #size-cells = <1>; >>>> + ranges; >>>> + >>> >>> >>> >>> I don't think there is a need to group these nodes under a parent node >>> that >>> doesn't give any additional information, especially when the CMUs are >>> scattered trough the whole address space, while we'd like to keep the >>> nodes >>> ordered by their addresses, as most platforms do. >>> >> >> This is exactly the same case as "cpus". I mean, "cpus" also doesn't >> provide >> any common information about child cpu nodes. This looks to me as a >> logical >> grouping and I have implemented same thing for cmu nodes. >> I am ok with removing this grouping Just want to understand the rational >> behind >> grouping cpus which seems similar to cmus. > > > The "cpus" node is a defined standard node that should be present at root of > device tree and include subnodes for all CPUs. This is a standard binding > defined for low level code to be able to simply find nodes of all CPUs in > the system - so they can expect that at /cpus node all the subnodes are > subsequent CPUs. > > >> Similarly "soc" is just a logical entity used to group SoC elements which >> looks >> optional to me. What are we achieving with this? Please help me in >> understanding >> this better. > > > Also "soc" has a slightly wider meaning. It is a node grouping all nodes > from a single address space - the node specifies #address-cells and > #size-cells of this address space and all the devices under this > "simple-bus" can be accessed using addresses in this format. In addition, it > separates board-level devices from generic SoC devices. > > Now, in case of "cmus", the only purpose is to group all CMU nodes together > and, while this improves readability a bit, it doesn't make the DT better > express the hardware topology, because the CMUs in the hardware are in fact > scattered through the whole address space, not under a contiguous block of > it, as the grouping would suggest. > > Best regards, > Tomasz -- 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
On 14 February 2014 08:54, Rahul Sharma <r.sh.open@gmail.com> wrote: > Thanks Tomasz, > > I will add these changes to v3. > > Regards, > Rahul Sharma. > > On 11 February 2014 15:34, Tomasz Figa <tomasz.figa@gmail.com> wrote: >> Hi Rahul, >> >> >> On 11.02.2014 06:22, Rahul Sharma wrote: >>> >>> Hi Tomasz, >>> >>> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote: >>>> >>>> Hi Rahul, Pankaj, Arun, >>>> >>>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc] >>>> >>>> I think it's good time to stop accepting DTS files like this and force >>>> new >>>> ones to use the proper structure with soc node, labels for every node and >>>> node references. >>> >>> >>> I am unable to find information on SoC node and grouping inside SoC node. >>> Please >>> share some pointers. >> >> >> Well, there is not much information needed about this. Basically all the >> devices built into the SoC should be listed under respective bus nodes or a >> single soc node, instead of root level. Such node should be a "simple-bus" >> and just group the components together to separate board-specific devices >> (which are still at root level) from SoC devices. >> >> Even though it might seem useless, it improves DT readability a bit and >> still most of the platforms use this approach, so for consistency, Exynos >> should use too. >> >> Just for reference, back in April 2013, in his review of S3C64xx DT series >> [1], Rob Herring requested that we don't submit any new device trees using >> flat approach and start using bus hierarchy. >> >> [1] >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html >> >> >>>> >>>>> + spi0_bus: spi0-bus { >>>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", >>>>> "gpa2-3"; >>>> >>>> >>>> >>>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3? >>>> >>> >>> I should align SPI1 with SPI0. >>> >> >> Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI, >> SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to >> the fact that the controller can only support one dedicated chip select and >> with direct GPIO control you can have more. >> >> What is the fourth pin here? >> As you said, these are CLK, SS, MISO, MOSI (gpa2-0 to gpa2-3). Fourth pin is CS. It can be defined as a simple GPIO but better to include it in the SPI pingroup as it belongs to there. Regards, Rahul Sharma. >> >>>> >>>>> + cpu@1 { >>>>> + device_type = "cpu"; >>>>> + compatible = "arm,cortex-a15"; >>>>> + reg = <1>; >>>>> + cci-control-port = <&cci_control1>; >>>>> + }; >>>>> + cpu@100 { >>>>> + device_type = "cpu"; >>>>> + compatible = "arm,cortex-a7"; >>>>> + reg = <0x100>; >>>>> + cci-control-port = <&cci_control0>; >>>>> + }; >>>>> + cpu@101 { >>>>> + device_type = "cpu"; >>>>> + compatible = "arm,cortex-a7"; >>>>> + reg = <0x101>; >>>>> + cci-control-port = <&cci_control0>; >>>>> + }; >>>>> + cpu@102 { >>>>> + device_type = "cpu"; >>>>> + compatible = "arm,cortex-a7"; >>>>> + reg = <0x102>; >>>>> + cci-control-port = <&cci_control0>; >>>>> + }; >>>>> + cpu@103 { >>>>> + device_type = "cpu"; >>>>> + compatible = "arm,cortex-a7"; >>>>> + reg = <0x103>; >>>>> + cci-control-port = <&cci_control0>; >>>>> + }; >>>>> + }; >>>>> + >>>>> + cmus { >>>>> + #address-cells = <1>; >>>>> + #size-cells = <1>; >>>>> + ranges; >>>>> + >>>> >>>> >>>> >>>> I don't think there is a need to group these nodes under a parent node >>>> that >>>> doesn't give any additional information, especially when the CMUs are >>>> scattered trough the whole address space, while we'd like to keep the >>>> nodes >>>> ordered by their addresses, as most platforms do. >>>> >>> >>> This is exactly the same case as "cpus". I mean, "cpus" also doesn't >>> provide >>> any common information about child cpu nodes. This looks to me as a >>> logical >>> grouping and I have implemented same thing for cmu nodes. >>> I am ok with removing this grouping Just want to understand the rational >>> behind >>> grouping cpus which seems similar to cmus. >> >> >> The "cpus" node is a defined standard node that should be present at root of >> device tree and include subnodes for all CPUs. This is a standard binding >> defined for low level code to be able to simply find nodes of all CPUs in >> the system - so they can expect that at /cpus node all the subnodes are >> subsequent CPUs. >> >> >>> Similarly "soc" is just a logical entity used to group SoC elements which >>> looks >>> optional to me. What are we achieving with this? Please help me in >>> understanding >>> this better. >> >> >> Also "soc" has a slightly wider meaning. It is a node grouping all nodes >> from a single address space - the node specifies #address-cells and >> #size-cells of this address space and all the devices under this >> "simple-bus" can be accessed using addresses in this format. In addition, it >> separates board-level devices from generic SoC devices. >> >> Now, in case of "cmus", the only purpose is to group all CMU nodes together >> and, while this improves readability a bit, it doesn't make the DT better >> express the hardware topology, because the CMUs in the hardware are in fact >> scattered through the whole address space, not under a contiguous block of >> it, as the grouping would suggest. >> >> Best regards, >> Tomasz -- 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
On 14.02.2014 12:28, Rahul Sharma wrote: > On 14 February 2014 08:54, Rahul Sharma <r.sh.open@gmail.com> wrote: >> Thanks Tomasz, >> >> I will add these changes to v3. >> >> Regards, >> Rahul Sharma. >> >> On 11 February 2014 15:34, Tomasz Figa <tomasz.figa@gmail.com> wrote: >>> Hi Rahul, >>> >>> >>> On 11.02.2014 06:22, Rahul Sharma wrote: >>>> >>>> Hi Tomasz, >>>> >>>> On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote: >>>>> >>>>> Hi Rahul, Pankaj, Arun, >>>>> >>>>> [adding linux-arm-kernel, devicetree MLs and DT people on Cc] >>>>> >>>>> I think it's good time to stop accepting DTS files like this and force >>>>> new >>>>> ones to use the proper structure with soc node, labels for every node and >>>>> node references. >>>> >>>> >>>> I am unable to find information on SoC node and grouping inside SoC node. >>>> Please >>>> share some pointers. >>> >>> >>> Well, there is not much information needed about this. Basically all the >>> devices built into the SoC should be listed under respective bus nodes or a >>> single soc node, instead of root level. Such node should be a "simple-bus" >>> and just group the components together to separate board-specific devices >>> (which are still at root level) from SoC devices. >>> >>> Even though it might seem useless, it improves DT readability a bit and >>> still most of the platforms use this approach, so for consistency, Exynos >>> should use too. >>> >>> Just for reference, back in April 2013, in his review of S3C64xx DT series >>> [1], Rob Herring requested that we don't submit any new device trees using >>> flat approach and start using bus hierarchy. >>> >>> [1] >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163659.html >>> >>> >>>>> >>>>>> + spi0_bus: spi0-bus { >>>>>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", >>>>>> "gpa2-3"; >>>>> >>>>> >>>>> >>>>> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3? >>>>> >>>> >>>> I should align SPI1 with SPI0. >>>> >>> >>> Are you sure that SPI0 is the correct one? SPI usually uses four pins - SDI, >>> SDO, SCK and nCS, but we always used to treat nCS as a simple GPIO, due to >>> the fact that the controller can only support one dedicated chip select and >>> with direct GPIO control you can have more. >>> >>> What is the fourth pin here? >>> > > As you said, these are CLK, SS, MISO, MOSI (gpa2-0 to gpa2-3). Fourth pin is > CS. It can be defined as a simple GPIO but better to include it in the > SPI pingroup > as it belongs to there. I have to disagree here. If you define a pin in pinctrl group then it is tied to this specific hardware function and you can't use it as GPIO. Since it's board specific to use it as HW chip select or GPIO chip select (the usual setup), it should not be included in this group. Best regards, Tomasz -- 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
diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi new file mode 100644 index 0000000..3f2c5c4 --- /dev/null +++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi @@ -0,0 +1,572 @@ +/* + * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source + * + * Copyright (c) 2013 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as device + * tree nodes are listed in this file. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +/ { + pinctrl@11600000 { + gpa0: gpa0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpa1: gpa1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpa2: gpa2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpb0: gpb0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpb1: gpb1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpb2: gpb2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpb3: gpb3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpb4: gpb4 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpb5: gpb5 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd0: gpd0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd1: gpd1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpd2: gpd2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpe0: gpe0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpe1: gpe1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpf0: gpf0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpf1: gpf1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpk0: gpk0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpx0: gpx0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpx1: gpx1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpx2: gpx2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpx3: gpx3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + uart0_data: uart0-data { + samsung,pins = "gpa0-0", "gpa0-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + uart0_fctl: uart0-fctl { + samsung,pins = "gpa0-2", "gpa0-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + uart1_data: uart1-data { + samsung,pins = "gpa1-0", "gpa1-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + uart1_fctl: uart1-fctl { + samsung,pins = "gpa1-2", "gpa1-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + uart2_data: uart2-data { + samsung,pins = "gpa1-4", "gpa1-5"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + spi0_bus: spi0-bus { + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2", "gpa2-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + spi1_bus: spi1-bus { + samsung,pins = "gpa2-5", "gpa2-6", "gpa2-7"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + usb3_vbus0_en: usb3-vbus0-en { + samsung,pins = "gpa2-4"; + samsung,pin-function = <1>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + i2s1_bus: i2s1-bus { + samsung,pins = "gpb0-0", "gpb0-1", "gpb0-2", "gpb0-3", + "gpb0-4"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + pcm1_bus: pcm1-bus { + samsung,pins = "gpb0-0", "gpb0-1", "gpb0-2", "gpb0-3", + "gpb0-4"; + samsung,pin-function = <3>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + spdif1_bus: spdif1-bus { + samsung,pins = "gpb0-0", "gpb0-1", "gpb0-2"; + samsung,pin-function = <4>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + spi2_bus: spi2-bus { + samsung,pins = "gpb1-0", "gpb1-1", "gpb1-2", "gpb1-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c0_hs_bus: i2c0-hs-bus { + samsung,pins = "gpb3-0", "gpb3-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c1_hs_bus: i2c1-hs-bus { + samsung,pins = "gpb3-2", "gpb3-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c2_hs_bus: i2c2-hs-bus { + samsung,pins = "gpb3-4", "gpb3-5"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c3_hs_bus: i2c3-hs-bus { + samsung,pins = "gpb3-6", "gpb3-7"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c4_bus: i2c4-bus { + samsung,pins = "gpb4-0", "gpb4-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c5_bus: i2c5-bus { + samsung,pins = "gpb4-2", "gpb4-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c6_bus: i2c6-bus { + samsung,pins = "gpb4-4", "gpb4-5"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c7_bus: i2c7-bus { + samsung,pins = "gpb4-6", "gpb4-7"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c8_bus: i2c8-bus { + samsung,pins = "gpb5-0", "gpb5-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c9_bus: i2c9-bus { + samsung,pins = "gpb5-2", "gpb5-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c10_bus: i2c10-bus { + samsung,pins = "gpb5-4", "gpb5-5"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + i2c11_bus: i2c11-bus { + samsung,pins = "gpb5-6", "gpb5-7"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + cam_gpio_a: cam-gpio-a { + samsung,pins = "gpe0-0", "gpe0-1", "gpe0-2", "gpe0-3", + "gpe0-4", "gpe0-5", "gpe0-6", "gpe0-7", + "gpe1-0", "gpe1-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + cam_gpio_b: cam-gpio-b { + samsung,pins = "gpf0-0", "gpf0-1", "gpf0-2", "gpf0-3", + "gpf1-0", "gpf1-1", "gpf1-2", "gpf1-3"; + samsung,pin-function = <3>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + cam_i2c1_bus: cam-i2c1-bus { + samsung,pins = "gpf0-2", "gpf0-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + cam_i2c0_bus: cam-i2c0-bus { + samsung,pins = "gpf0-0", "gpf0-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <0>; + }; + + cam_spi0_bus: cam-spi0-bus { + samsung,pins = "gpf1-0", "gpf1-1", "gpf1-2", "gpf1-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + + cam_spi1_bus: cam-spi1-bus { + samsung,pins = "gpf1-4", "gpf1-5", "gpf1-6", "gpf1-7"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <0>; + }; + }; + + pinctrl@12290000 { + gpc0: gpc0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpc1: gpc1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpc2: gpc2 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpc3: gpc3 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpc4: gpc4 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + sd0_clk: sd0-clk { + samsung,pins = "gpc0-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd0_cmd: sd0-cmd { + samsung,pins = "gpc0-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd0_bus1: sd0-bus-width1 { + samsung,pins = "gpc0-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd0_bus4: sd0-bus-width4 { + samsung,pins = "gpc0-3", "gpc0-4", "gpc0-5"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd0_bus8: sd0-bus-width8 { + samsung,pins = "gpc3-0", "gpc3-1", "gpc3-2", "gpc3-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd0_rdqs: sd0-rdqs { + samsung,pins = "gpc0-6"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd1_clk: sd1-clk { + samsung,pins = "gpc1-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd1_cmd: sd1-cmd { + samsung,pins = "gpc1-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd1_bus1: sd1-bus-width1 { + samsung,pins = "gpc1-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd1_bus4: sd1-bus-width4 { + samsung,pins = "gpc1-3", "gpc1-4", "gpc1-5"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd1_bus8: sd1-bus-width8 { + samsung,pins = "gpc4-0", "gpc4-1", "gpc4-2", "gpc4-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd2_clk: sd2-clk { + samsung,pins = "gpc2-0"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd2_cmd: sd2-cmd { + samsung,pins = "gpc2-1"; + samsung,pin-function = <2>; + samsung,pin-pud = <0>; + samsung,pin-drv = <3>; + }; + + sd2_cd: sd2-cd { + samsung,pins = "gpc2-2"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd2_bus1: sd2-bus-width1 { + samsung,pins = "gpc2-3"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + + sd2_bus4: sd2-bus-width4 { + samsung,pins = "gpc2-4", "gpc2-5", "gpc2-6"; + samsung,pin-function = <2>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + }; + + pinctrl@128B0000 { + gpz0: gpz0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpz1: gpz1 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + }; +}; diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi new file mode 100644 index 0000000..32a95c7 --- /dev/null +++ b/arch/arm/boot/dts/exynos5260.dtsi @@ -0,0 +1,317 @@ +/* + * SAMSUNG EXYNOS5260 SoC device tree source + * + * Copyright (c) 2013 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include "skeleton.dtsi" +#include "exynos5260-pinctrl.dtsi" + +#include <dt-bindings/clk/exynos5260-clk.h> + +/ { + compatible = "samsung,exynos5260"; + interrupt-parent = <&gic>; + + aliases { + pinctrl0 = &pinctrl_0; + pinctrl1 = &pinctrl_1; + pinctrl2 = &pinctrl_2; + }; + + chipid@10000000 { + compatible = "samsung,exynos4210-chipid"; + reg = <0x10000000 0x100>; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0>; + cci-control-port = <&cci_control1>; + }; + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <1>; + cci-control-port = <&cci_control1>; + }; + cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x100>; + cci-control-port = <&cci_control0>; + }; + cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x101>; + cci-control-port = <&cci_control0>; + }; + cpu@102 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x102>; + cci-control-port = <&cci_control0>; + }; + cpu@103 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x103>; + cci-control-port = <&cci_control0>; + }; + }; + + cmus { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + cmu_top: clock-controller@10010000 { + compatible = "exynos5260-cmu-top", "samsung,exynos5260-clock"; + reg = <0x10010000 0x10000>; + #clock-cells = <1>; + }; + + cmu_peri: clock-controller@10200000 { + compatible = "exynos5260-cmu-peri", "samsung,exynos5260-clock"; + reg = <0x10200000 0x10000>; + #clock-cells = <1>; + }; + + cmu_egl: clock-controller@10600000 { + compatible = "exynos5260-cmu-egl", "samsung,exynos5260-clock"; + reg = <0x10600000 0x10000>; + #clock-cells = <1>; + }; + + cmu_kfc: clock-controller@10700000 { + compatible = "exynos5260-cmu-kfc", "samsung,exynos5260-clock"; + reg = <0x10700000 0x10000>; + #clock-cells = <1>; + }; + + cmu_g2d: clock-controller@10A00000 { + compatible = "exynos5260-cmu-g2d", "samsung,exynos5260-clock"; + reg = <0x10A00000 0x10000>; + #clock-cells = <1>; + }; + + cmu_mif: clock-controller@10CE0000 { + compatible = "exynos5260-cmu-mif", "samsung,exynos5260-clock"; + reg = <0x10CE0000 0x10000>; + #clock-cells = <1>; + }; + + cmu_mfc: clock-controller@11090000 { + compatible = "exynos5260-cmu-mfc", "samsung,exynos5260-clock"; + reg = <0x11090000 0x10000>; + #clock-cells = <1>; + }; + + cmu_g3d: clock-controller@11830000 { + compatible = "exynos5260-cmu-g3d", "samsung,exynos5260-clock"; + reg = <0x11830000 0x10000>; + #clock-cells = <1>; + }; + + cmu_fsys: clock-controller@122E0000 { + compatible = "exynos5260-cmu-fsys", "samsung,exynos5260-clock"; + reg = <0x122E0000 0x10000>; + #clock-cells = <1>; + }; + + cmu_aud: clock-controller@128C0000 { + compatible = "exynos5260-cmu-aud", "samsung,exynos5260-clock"; + reg = <0x128C0000 0x10000>; + #clock-cells = <1>; + }; + + cmu_isp: clock-controller@133C0000 { + compatible = "exynos5260-cmu-isp", "samsung,exynos5260-clock"; + reg = <0x133C0000 0x10000>; + #clock-cells = <1>; + }; + + cmu_gscl: clock-controller@13F00000 { + compatible = "exynos5260-cmu-gscl", "samsung,exynos5260-clock"; + reg = <0x13F00000 0x10000>; + #clock-cells = <1>; + }; + + cmu_disp: clock-controller@14550000 { + compatible = "exynos5260-cmu-disp", "samsung,exynos5260-clock"; + reg = <0x14550000 0x10000>; + #clock-cells = <1>; + }; + }; + + gic: interrupt-controller@10481000 { + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; + #interrupt-cells = <3>; + #address-cells = <0>; + #size-cells = <0>; + interrupt-controller; + reg = <0x10481000 0x1000>, + <0x10482000 0x1000>, + <0x10484000 0x2000>, + <0x10486000 0x2000>; + interrupts = <1 9 0xf04>; + }; + + mct@100B0000 { + compatible = "samsung,exynos4210-mct"; + reg = <0x100B0000 0x1000>; + interrupt-controller; + #interrups-cells = <1>; + interrupt-parent = <&mct_map>; + interrupts = <0>, <1>, <2>, <3>, + <4>, <5>, <6>, <7>, + <8>, <9>, <10>, <11>; + clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>; + clock-names = "fin_pll", "mct"; + + mct_map: mct-map { + #interrupt-cells = <1>; + #address-cells = <0>; + #size-cells = <0>; + interrupt-map = <0 &gic 0 104 0>, + <1 &gic 0 105 0>, + <2 &gic 0 106 0>, + <3 &gic 0 107 0>, + <4 &gic 0 122 0>, + <5 &gic 0 123 0>, + <6 &gic 0 124 0>, + <7 &gic 0 125 0>, + <8 &gic 0 126 0>, + <9 &gic 0 127 0>, + <10 &gic 0 128 0>, + <11 &gic 0 129 0>; + }; + }; + + cci@10F00000 { + compatible = "arm,cci-400"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x10F00000 0x1000>; + ranges = <0x0 0x10F00000 0x6000>; + + cci_control0: slave-if@4000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace"; + reg = <0x4000 0x1000>; + }; + + cci_control1: slave-if@5000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace"; + reg = <0x5000 0x1000>; + }; + }; + + pinctrl_0: pinctrl@11600000 { + compatible = "samsung,exynos5260-pinctrl"; + reg = <0x11600000 0x1000>; + interrupts = <0 79 0>; + + wakeup-interrupt-controller { + compatible = "samsung,exynos4210-wakeup-eint"; + interrupt-parent = <&gic>; + interrupts = <0 32 0>; + }; + }; + + pinctrl_1: pinctrl@12290000 { + compatible = "samsung,exynos5260-pinctrl"; + reg = <0x12290000 0x1000>; + interrupts = <0 157 0>; + }; + + pinctrl_2: pinctrl@128B0000 { + compatible = "samsung,exynos5260-pinctrl"; + reg = <0x128B0000 0x1000>; + interrupts = <0 243 0>; + }; + + serial@12C00000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x12C00000 0x100>; + interrupts = <0 146 0>; + clocks = <&cmu_peri PERI_CLK_UART0>, <&cmu_peri PERI_SCLK_UART0>; + clock-names = "uart", "clk_uart_baud0"; + status = "disabled"; + }; + + serial@12C10000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x12C10000 0x100>; + interrupts = <0 147 0>; + clocks = <&cmu_peri PERI_CLK_UART1>, <&cmu_peri PERI_SCLK_UART1>; + clock-names = "uart", "clk_uart_baud0"; + status = "disabled"; + }; + + serial@12C20000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x12C20000 0x100>; + interrupts = <0 148 0>; + clocks = <&cmu_peri PERI_CLK_UART2>, <&cmu_peri PERI_SCLK_UART2>; + clock-names = "uart", "clk_uart_baud0"; + status = "disabled"; + }; + + serial@12860000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x12860000 0x100>; + interrupts = <0 145 0>; + clocks = <&cmu_aud AUD_CLK_AUD_UART>, <&cmu_aud AUD_SCLK_AUD_UART>; + clock-names = "uart", "clk_uart_baud0"; + status = "disabled"; + }; + + mmc_0: mmc0@12140000 { + compatible = "samsung,exynos5250-dw-mshc"; + reg = <0x12140000 0x2000>; + interrupts = <0 156 0>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top TOP_SCLK_MMC0>; + clock-names = "biu", "ciu"; + fifo-depth = <0x40>; + status = "disabled"; + }; + + mmc_1: mmc1@12150000 { + compatible = "samsung,exynos5250-dw-mshc"; + reg = <0x12150000 0x2000>; + interrupts = <0 158 0>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cmu_fsys FSYS_CLK_MMC1>, <&cmu_top TOP_SCLK_MMC1>; + clock-names = "biu", "ciu"; + fifo-depth = <0x40>; + status = "disabled"; + }; + + mmc_2: mmc2@12160000 { + compatible = "samsung,exynos5250-dw-mshc"; + reg = <0x12160000 0x2000>; + interrupts = <0 159 0>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cmu_fsys FSYS_CLK_MMC2>, <&cmu_top TOP_SCLK_MMC2>; + clock-names = "biu", "ciu"; + fifo-depth = <0x40>; + status = "disabled"; + }; +};