dt: device tree bindings and data for EMIF and DDR
Subsystems (2)
v2 cover dt: device tree bindings and data for EMIF and DDR
This is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future.
The second patch provides the bindings for the EMIF controller.
The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards.
Thanks to Rajendra for answering my numerous queries on device tree.
This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version.
Aneesh V (3):
dt: device tree bindings for DDR memories
dt: device tree bindings for TI's EMIF sdram controller arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards
Documentation/devicetree/bindings/ddr/ddr.txt | 114 ++++++++++++++++++++ .../devicetree/bindings/ddr/ddr_timings.txt | 62 +++++++++++ .../bindings/memory-controllers/ti/emif.txt | 64 +++++++++++ arch/arm/boot/dts/omap-common-devices.dtsi | 63 +++++++++++ arch/arm/boot/dts/omap4-panda.dts | 13 +++ arch/arm/boot/dts/omap4-sdp.dts | 13 +++ arch/arm/boot/dts/omap4.dtsi | 19 ++++ 7 files changed, 348 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/ddr/ddr.txt create mode 100644 Documentation/devicetree/bindings/ddr/ddr_timings.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti/emif.txt create mode 100644 arch/arm/boot/dts/omap-common-devices.dtsi
RFC PATCH v2 1/3 dt: device tree bindings for DDR memories
device tree bindings for DDR SDRAM memories compliant to JEDEC standards. Currently only DDR3 and LPDDR2 have been considered for this binding. Properties for other memory types(DDR2 etc) could be added to this binding on a need-basis.
The 'ddr' binding in-turn uses another binding 'ddr-timings' for specifying the AC timing parameters of the memory device at different speed-bins.
--- Documentation/devicetree/bindings/ddr/ddr.txt | 114 ++++++++++++++++++++ .../devicetree/bindings/ddr/ddr_timings.txt | 62 +++++++++++ 2 files changed, 176 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/ddr/ddr.txt create mode 100644 Documentation/devicetree/bindings/ddr/ddr_timings.txt
Documentation/devicetree/bindings/ddr/ddr.txt new file +114 -0
@@ -0,0 +1,114 @@ +* DDR SDRAM memories compliant to JEDEC specifications JESD209-2(LPDDR2) + or JESD79-3(DDR3). + +Required properties: +- compatible : Should be one of - "jedec,ddr3", "jedec,lpddr2-nvm", + "jedec,lpddr2-s2", "jedec,lpddr2-s4" + + "ti,jedec-ddr3" should be listed if the memory part is DDR3 type + + "ti,jedec-lpddr2-s2" should be listed if the memory part is LPDDR2-S2 type + + "ti,jedec-lpddr2-s4" should be listed if the memory part is LPDDR2-S4 type + + "ti,jedec-lpddr2-nvm" should be listed if the memory part is LPDDR2-NVM type + +- density : string representing the density of the device in terms of + Mb (mega bits). Following are the allowed values: "64Mb", "128Mb", + "256Mb", "512Mb", "1Gb", "2Gb", "4Gb", "8Gb", "16Gb", or "32Gb" + +- io-width : string representing the io width: "x8", "x16" or "x32". + +Optional properties: + +The following optional properties represent the minimum value of some AC +timing parameters of the DDR device in terms of number of clock cycles. +These values shall be obtained from the device data-sheet. + +The suffix nCK indicates that the unit for these parameters is number +of DDR clock cycles. Note: In LPDDR2 spec and data-sheets tCK is used +inter-changeably for nCK. Both are equivalent in this context. + +- tRRD-min-nCK +- tWTR-min-nCK +- tXP-min-nCK +- tRTP-min-nCK +- tCKE-min-nCK +- tRPab-min-nCK /* LPDDR2 only */ +- tRCD-min-nCK /* LPDDR2 only */ +- tWR-min-nCK /* LPDDR2 only */ +- tRASmin-min-nCK /* LPDDR2 only */ +- tCKESR-min-nCK /* LPDDR2 only */ +- tFAW-min-nCK /* LPDDR2 only */ +- tZQCS-min-nCK /* DDR3 only */ +- tZQoper-min-nCK /* DDR3 only */ +- tZQinit-min-nCK /* DDR3 only */ +- tXS-min-nCK /* DDR3 only */ + +Child nodes: +- The ddr node may have one or more child nodes of type "ddr-timings". + "ddr-timings" provides AC timing parameters of the device for + a given speed-bin. The user may provide the timings for as many + speed-bins as is required. Please see Documentation/devicetree/ + bindings/ddr/ddr-timings.txt for more information on "ddr-timings" + +Example: + +elpida_ECB240ABACN : ddr { + compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4"; + density = "2Gb"; + io-width = "x32"; + + tRPab-min-nCK = <3>; + tRCD-min-nCK = <3>; + tWR-min-nCK = <3>; + tRASmin-min-nCK = <3>; + tRRD-min-nCK = <2>; + tWTR-min-nCK = <2>; + tXP-min-nCK = <2>; + tRTP-min-nCK = <2>; + tCKE-min-nCK = <3>; + tCKESR-min-nCK = <3>; + tFAW-min-nCK = <8>; + + timings_elpida_ECB240ABACN_400mhz: ddr-timings { + min-freq = <10000000>; + max-freq = <400000000>; + tRP-ps = <21000>; + tRCD-ps = <18000>; + tWR-ps = <15000>; + tRAS-min-ps = <42000:; + tRRD-ps = <10000>; + tWTR-ps = <7500>; + tXP-ps = <7500>; + tRTP-ps = <7500>; + tCKESR-ps = <15000>; + tDQSCK-max-ps = <5500>; + tFAW-ps = <50000>; + tZQCS-ps = <90000>; + tZQoper-ps = <360000>; + tZQinit-ps = <1000000>; + tRAS-max-ns = <70000>; + }; + + timings_elpida_ECB240ABACN_200mhz: ddr-timings { + min-freq = <10000000>; + max-freq = <200000000>; + tRP-ps = <21000>; + tRCD-ps = <18000>; + tWR-ps = <15000>; + tRAS-min-ps = <42000:; + tRRD-ps = <10000>; + tWTR-ps = <10000>; + tXP-ps = <7500>; + tRTP-ps = <7500>; + tCKESR-ps = <15000>; + tDQSCK-max-ps = <5500>; + tFAW-ps = <50000>; + tZQCS-ps = <90000>; + tZQoper-ps = <360000>; + tZQinit-ps = <1000000>; + tRAS-max-ns = <70000>; + }; + +}
Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +62 -0
62 lines not on this page · raw message
Signature · 1 line
1.7.1
RFC PATCH v2 1/3 dt: device tree bindings for DDR memories
Hi,
Some comments below, but also a more general question: How much of this generic data makes sense to encode in the device tree? Final hardware configuration usually has to take into consideration board layout/signal delays, etc, and that's not part of this binding.
Quoted 14 lines · Aneesh V
Documentation/devicetree/bindings/ddr/ddr.txt new file +8
-0@@ -0,0 +1,114 @@ +* DDR SDRAM memories compliant to JEDEC specifications JESD209-2(LPDDR2) + ?or JESD79-3(DDR3). + +Required properties: +- compatible : Should be one of - "jedec,ddr3", "jedec,lpddr2-nvm", + ?"jedec,lpddr2-s2", "jedec,lpddr2-s4" + + ?"ti,jedec-ddr3" should be listed if the memory part is DDR3 type
Documentation/devicetree/bindings/ddr/ddr.txt line 18
Quoted 10 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +10
-0+ + ?"ti,jedec-lpddr2-s2" should be listed if the memory part is LPDDR2-S2 type + + ?"ti,jedec-lpddr2-s4" should be listed if the memory part is LPDDR2-S4 type + + ?"ti,jedec-lpddr2-nvm" should be listed if the memory part is LPDDR2-NVM type + +- density ?: string representing the density of the device in terms of + ?Mb (mega bits). Following are the allowed values: "64Mb", "128Mb", + ?"256Mb", "512Mb", "1Gb", "2Gb", "4Gb", "8Gb", "16Gb", or "32Gb"
No, please encode as a two-cell integer instead.
Documentation/devicetree/bindings/ddr/ddr.txt line 20
Quoted 1 line
Documentation/devicetree/bindings/ddr/ddr.txt new file +1
-0+- io-width : string representing the io width: "x8", "x16" or "x32".
No, encode as an integer.
Documentation/devicetree/bindings/ddr/ddr.txt line 30
Quoted 10 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +10
-0+ +Optional properties: + +The following optional properties represent the minimum value of some AC +timing parameters of the DDR device in terms of number of clock cycles. +These values shall be obtained from the device data-sheet. + +The suffix nCK indicates that the unit for these parameters is number +of DDR clock cycles. Note: In LPDDR2 spec and data-sheets tCK is used +inter-changeably for nCK. Both are equivalent in this context.
Please use only lower characters in property names unless absolutely necessary, which this doesn't qualify as, in my opinion.
Also, can't these strings be shortened a bit? All of them have '-min' in common, and none of them seem to be very devicetree-like in their naming.
Finally, the "lpddr2" and "ddr3" properties could just be prefixed with "lpddr2,<propertyname>" instead.
Quoted 34 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +34
-0+ +- tRRD-min-nCK +- tWTR-min-nCK +- tXP-min-nCK +- tRTP-min-nCK +- tCKE-min-nCK +- tRPab-min-nCK ? ? ? ? ? ? ? ?/* LPDDR2 only */ +- tRCD-min-nCK ? ? ? ? /* LPDDR2 only */ +- tWR-min-nCK ? ? ? ? ?/* LPDDR2 only */ +- tRASmin-min-nCK ? ? ?/* LPDDR2 only */ +- tCKESR-min-nCK ? ? ? /* LPDDR2 only */ +- tFAW-min-nCK ? ? ? ? /* LPDDR2 only */ +- tZQCS-min-nCK ? ? ? ? ? ? ? ?/* DDR3 only */ +- tZQoper-min-nCK ? ? ?/* DDR3 only */ +- tZQinit-min-nCK ? ? ?/* DDR3 only */ +- tXS-min-nCK ? ? ? ? ?/* DDR3 only */ + +Child nodes: +- The ddr node may have one or more child nodes of type "ddr-timings". + ?"ddr-timings" provides AC timing parameters of the device for + ?a given speed-bin. The user may provide the timings for as many + ?speed-bins as is required. Please see Documentation/devicetree/ + ?bindings/ddr/ddr-timings.txt for more information on "ddr-timings" + +Example: + +elpida_ECB240ABACN : ddr { + ? ? ? compatible ? ? ?= "Elpida,ECB240ABACN","jedec,lpddr2-s4"; + ? ? ? density ? ? ? ? = "2Gb"; + ? ? ? io-width ? ? ? ?= "x32"; + + ? ? ? tRPab-min-nCK ? = <3>; + ? ? ? tRCD-min-nCK ? ?= <3>; + ? ? ? tWR-min-nCK ? ? = <3>;
Documentation/devicetree/bindings/ddr/ddr.txt line 73
Quoted 10 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +10
-0+ ? ? ? tRASmin-min-nCK = <3>; + ? ? ? tRRD-min-nCK ? ?= <2>; + ? ? ? tWTR-min-nCK ? ?= <2>; + ? ? ? tXP-min-nCK ? ? = <2>; + ? ? ? tRTP-min-nCK ? ?= <2>; + ? ? ? tCKE-min-nCK ? ?= <3>; + ? ? ? tCKESR-min-nCK ?= <3>; + ? ? ? tFAW-min-nCK ? ?= <8>; + + ? ? ? timings_elpida_ECB240ABACN_400mhz: ddr-timings {
You will need a unit address here.
Quoted 10 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +10
-0+ ? ? ? ? ? ? ? min-freq ? ? ? ?= <10000000>; + ? ? ? ? ? ? ? max-freq ? ? ? ?= <400000000>; + ? ? ? ? ? ? ? tRP-ps ? ? ? ? ?= <21000>; + ? ? ? ? ? ? ? tRCD-ps ? ? ? ? = <18000>; + ? ? ? ? ? ? ? tWR-ps ? ? ? ? ?= <15000>; + ? ? ? ? ? ? ? tRAS-min-ps ? ? = <42000:; + ? ? ? ? ? ? ? tRRD-ps ? ? ? ? = <10000>; + ? ? ? ? ? ? ? tWTR-ps ? ? ? ? = <7500>; + ? ? ? ? ? ? ? tXP-ps ? ? ? ? ?= <7500>; + ? ? ? ? ? ? ? tRTP-ps ? ? ? ? = <7500>;
Documentation/devicetree/bindings/ddr/ddr.txt line 93
Quoted 10 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +10
-0+ ? ? ? ? ? ? ? tCKESR-ps ? ? ? = <15000>; + ? ? ? ? ? ? ? tDQSCK-max-ps ? = <5500>; + ? ? ? ? ? ? ? tFAW-ps ? ? ? ? = <50000>; + ? ? ? ? ? ? ? tZQCS-ps ? ? ? ?= <90000>; + ? ? ? ? ? ? ? tZQoper-ps ? ? ?= <360000>; + ? ? ? ? ? ? ? tZQinit-ps ? ? ?= <1000000>; + ? ? ? ? ? ? ? tRAS-max-ns ? ? = <70000>; + ? ? ? }; + + ? ? ? timings_elpida_ECB240ABACN_200mhz: ddr-timings {
Same here, since you have more than one table. See previous discussions about emc tables on tegra (I'll repost that series this week).
Documentation/devicetree/bindings/ddr/ddr.txt line 99
Quoted 6 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +6
-0+ ? ? ? ? ? ? ? min-freq ? ? ? ?= <10000000>; + ? ? ? ? ? ? ? max-freq ? ? ? ?= <200000000>; + ? ? ? ? ? ? ? tRP-ps ? ? ? ? ?= <21000>; + ? ? ? ? ? ? ? tRCD-ps ? ? ? ? = <18000>; + ? ? ? ? ? ? ? tWR-ps ? ? ? ? ?= <15000>; + ? ? ? ? ? ? ? tRAS-min-ps ? ? = <42000:;
Typo
Quoted 20 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +14
-0+ ? ? ? ? ? ? ? tRRD-ps ? ? ? ? = <10000>; + ? ? ? ? ? ? ? tWTR-ps ? ? ? ? = <10000>; + ? ? ? ? ? ? ? tXP-ps ? ? ? ? ?= <7500>; + ? ? ? ? ? ? ? tRTP-ps ? ? ? ? = <7500>; + ? ? ? ? ? ? ? tCKESR-ps ? ? ? = <15000>; + ? ? ? ? ? ? ? tDQSCK-max-ps ? = <5500>; + ? ? ? ? ? ? ? tFAW-ps ? ? ? ? = <50000>; + ? ? ? ? ? ? ? tZQCS-ps ? ? ? ?= <90000>; + ? ? ? ? ? ? ? tZQoper-ps ? ? ?= <360000>; + ? ? ? ? ? ? ? tZQinit-ps ? ? ?= <1000000>; + ? ? ? ? ? ? ? tRAS-max-ns ? ? = <70000>; + ? ? ? }; + +}Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +0
-0
Documentation/devicetree/bindings/ddr/ddr_timings.txt line 6
Quoted 6 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +6
-0@@ -0,0 +1,62 @@ +* AC timing parameters of DDR memories for a given speed-bin + ?At the moment properties for only LPDDR2 and DDR3 have been added + +Required properties: +- min-freq : minimum DDR clock frequency for the speed-bin +- max-freq : maximum DDR clock frequency for the speed-bin
There should be a compatible field here too, especially if the binding ever has to be revised.
Documentation/devicetree/bindings/ddr/ddr_timings.txt
Quoted 12 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +12
-0+ +Optional properties: + +The following properties represent AC timing parameters from the memory +data-sheet of the device for a given speed-bin. All these properties are +of type <u32> and "-ps", "-ns", "-nCK" etc in the name indicates the +unit of the corresponding parameter: + ?ps - pico seconds + ?ns - nano seconds + ?nCK - number of DDR clock cycles. Please note that in LPDDR2 spec and + ?data-sheets tCK is used inter-changeably for nCK. Both are equivalent + ?in this context.
Seems noisy to include the units on every single property instead of just in the bindings.
Quoted 11 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +11
-0+ +- tRCD-ps +- tWR-ps +- tRAS-min-ps +- tRRD-ps +- tWTR-ps +- tXP-ps +- tRTP-ps +- tDQSCK-max-ps +- tFAW-ps +- tZQCS-ps
Documentation/devicetree/bindings/ddr/ddr_timings.txt
Quoted 10 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +10
-0+- tZQinit-ps +- tRP-ps ? ? ? /* DDR3 only */ +- tRC-ps ? ? ? /* DDR3 only */ +- tXSDLL-nCK ? /* DDR3 only */ +- tCKE-ps ? ? ?/* DDR3 only */ +- tZQoper-ps ? /* DDR3 only */ +- tRPab-ps ? ? /* LPDDR2 only */ +- tZQCL-ps ? ? /* LPDDR2 only */ +- tCKESR-ps ? ?/* LPDDR2 only */ +- tRAS-max-ns ?/* LPDDR2 only */
Same above about type-specific properties.
Quoted 30 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +23
-1+ +Example: + +timings_elpida_ECB240ABACN_400mhz: ddr-timings { + ? ? ? min-freq ? ? ? ?= <10000000>; + ? ? ? max-freq ? ? ? ?= <400000000>; + ? ? ? tRPab-ps ? ? ? ?= <21000>; + ? ? ? tRCD-ps ? ? ? ? = <18000>; + ? ? ? tWR-ps ? ? ? ? ?= <15000>; + ? ? ? tRAS-min-ps ? ? = <42000:; + ? ? ? tRRD-ps ? ? ? ? = <10000>; + ? ? ? tWTR-ps ? ? ? ? = <7500>; + ? ? ? tXP-ps ? ? ? ? ?= <7500>; + ? ? ? tRTP-ps ? ? ? ? = <7500>; + ? ? ? tCKESR-ps ? ? ? = <15000>; + ? ? ? tDQSCK-max-ps ? = <5500>; + ? ? ? tFAW-ps ? ? ? ? = <50000>; + ? ? ? tZQCS-ps ? ? ? ?= <90000>; + ? ? ? tZQCL-ps ? ? ? ?= <360000>; + ? ? ? tZQinit-ps ? ? ?= <1000000>; + ? ? ? tRAS-max-ns ? ? = <70000>; +}; + --1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html
RFC PATCH v2 1/3 dt: device tree bindings for DDR memories
Hi Olof,
Quoted 6 lines · Olof Johansson
Hi,
Some comments below, but also a more general question: How much of this generic data makes sense to encode in the device tree? Final hardware configuration usually has to take into consideration board layout/signal delays, etc, and that's not part of this binding.
The JEDEC specifies base values for all timing parameters. But Vendors can improve on these timings and provide better values. Using device specific timing values therefore provides scope for optimization.
Everything that I have encoded here is needed by our driver to re-configure our SDRAM controller during DVFS. In fact, I have not listed all AC timing parameters in the spec in this binding, leaving the rest for future users to add if they need them.
Quoted 22 lines · Aneesh V
Quoted 19 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +12
-0@@ -0,0 +1,114 @@ +* DDR SDRAM memories compliant to JEDEC specifications JESD209-2(LPDDR2) + or JESD79-3(DDR3). + +Required properties: +- compatible : Should be one of - "jedec,ddr3", "jedec,lpddr2-nvm", + "jedec,lpddr2-s2", "jedec,lpddr2-s4" + + "ti,jedec-ddr3" should be listed if the memory part is DDR3 type + + "ti,jedec-lpddr2-s2" should be listed if the memory part is LPDDR2-S2 type + + "ti,jedec-lpddr2-s4" should be listed if the memory part is LPDDR2-S4 type
Quoted 8 lines
Documentation/devicetree/bindings/ddr/ddr.txt line 18
Quoted 6 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +6
-0+ + "ti,jedec-lpddr2-nvm" should be listed if the memory part is LPDDR2-NVM type + +- density : string representing the density of the device in terms of + Mb (mega bits). Following are the allowed values: "64Mb", "128Mb", + "256Mb", "512Mb", "1Gb", "2Gb", "4Gb", "8Gb", "16Gb", or "32Gb"No, please encode as a two-cell integer instead.
That is what I thought of doing initially. But I felt that "32Gb" is more readable than 34359738368 or 33554432(if the unit is Mb).
Quoted 4 lines
Documentation/devicetree/bindings/ddr/ddr.txt line 20
Quoted 2 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +1
-0+- io-width : string representing the io width: "x8", "x16" or "x32".No, encode as an integer.
Ok.
Quoted 14 lines
Documentation/devicetree/bindings/ddr/ddr.txt line 30
Quoted 11 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +10
-0+ +Optional properties: + +The following optional properties represent the minimum value of some AC +timing parameters of the DDR device in terms of number of clock cycles. +These values shall be obtained from the device data-sheet. + +The suffix nCK indicates that the unit for these parameters is number +of DDR clock cycles. Note: In LPDDR2 spec and data-sheets tCK is used +inter-changeably for nCK. Both are equivalent in this context.Please use only lower characters in property names unless absolutely necessary, which this doesn't qualify as, in my opinion.
I have used the names "as is" from the spec. Thought that might be useful when users extract data from the data-sheets in the future to create dts for new devices.
Quoted 4 lines
Also, can't these strings be shortened a bit? All of them have '-min' in common, and none of them seem to be very devicetree-like in their naming.
Most of these have a counter part in the timings node. That is we have both "tCKESR-min-nCK" and "tCKESR-ps" albeit in different nodes.
Quoted 3 lines
Finally, the "lpddr2" and "ddr3" properties could just be prefixed with "lpddr2,<propertyname>" instead.
Makes sense. But a given node will have data for only either of them,
not both and the compatible property will clearly mention what the data is for. Would you still like to have the above scheme?
Quoted 39 lines
Quoted 39 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +38
-0+ +- tRRD-min-nCK +- tWTR-min-nCK +- tXP-min-nCK +- tRTP-min-nCK +- tCKE-min-nCK +- tRPab-min-nCK /* LPDDR2 only */ +- tRCD-min-nCK /* LPDDR2 only */ +- tWR-min-nCK /* LPDDR2 only */ +- tRASmin-min-nCK /* LPDDR2 only */ +- tCKESR-min-nCK /* LPDDR2 only */ +- tFAW-min-nCK /* LPDDR2 only */ +- tZQCS-min-nCK /* DDR3 only */ +- tZQoper-min-nCK /* DDR3 only */ +- tZQinit-min-nCK /* DDR3 only */ +- tXS-min-nCK /* DDR3 only */ + +Child nodes: +- The ddr node may have one or more child nodes of type "ddr-timings". + "ddr-timings" provides AC timing parameters of the device for + a given speed-bin. The user may provide the timings for as many + speed-bins as is required. Please see Documentation/devicetree/ + bindings/ddr/ddr-timings.txt for more information on "ddr-timings" + +Example: + +elpida_ECB240ABACN : ddr { + compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4"; + density = "2Gb"; + io-width = "x32"; + + tRPab-min-nCK =<3>; + tRCD-min-nCK =<3>; + tWR-min-nCK =<3>; + tRASmin-min-nCK =<3>; + tRRD-min-nCK =<2>; + tWTR-min-nCK =<2>; + tXP-min-nCK =<2>;
Quoted 8 lines
Documentation/devicetree/bindings/ddr/ddr.txt line 73
Quoted 6 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +6
-0+ tRTP-min-nCK =<2>; + tCKE-min-nCK =<3>; + tCKESR-min-nCK =<3>; + tFAW-min-nCK =<8>; + + timings_elpida_ECB240ABACN_400mhz: ddr-timings {You will need a unit address here.
Ok. ddr-timing at 0, ddr-timings at 1 etc, right?
Quoted 22 lines
Quoted 11 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +10
-0+ min-freq =<10000000>; + max-freq =<400000000>; + tRP-ps =<21000>; + tRCD-ps =<18000>; + tWR-ps =<15000>; + tRAS-min-ps =<42000:; + tRRD-ps =<10000>; + tWTR-ps =<7500>; + tXP-ps =<7500>; + tRTP-ps =<7500>;Documentation/devicetree/bindings/ddr/ddr.txt line 93
Quoted 10 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +10
-0+ tCKESR-ps =<15000>; + tDQSCK-max-ps =<5500>; + tFAW-ps =<50000>; + tZQCS-ps =<90000>; + tZQoper-ps =<360000>; + tZQinit-ps =<1000000>; + tRAS-max-ns =<70000>; + }; + + timings_elpida_ECB240ABACN_200mhz: ddr-timings {
Quoted 3 lines
Same here, since you have more than one table. See previous discussions about emc tables on tegra (I'll repost that series this week).
Ok.
Quoted 9 lines
Documentation/devicetree/bindings/ddr/ddr.txt line 99
Quoted 7 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +6
-0+ min-freq =<10000000>; + max-freq =<200000000>; + tRP-ps =<21000>; + tRCD-ps =<18000>; + tWR-ps =<15000>; + tRAS-min-ps =<42000:;Typo
Will fix.
Quoted 22 lines
Quoted 22 lines
Documentation/devicetree/bindings/ddr/ddr.txt new file +14
-0+ tRRD-ps =<10000>; + tWTR-ps =<10000>; + tXP-ps =<7500>; + tRTP-ps =<7500>; + tCKESR-ps =<15000>; + tDQSCK-max-ps =<5500>; + tFAW-ps =<50000>; + tZQCS-ps =<90000>; + tZQoper-ps =<360000>; + tZQinit-ps =<1000000>; + tRAS-max-ns =<70000>; + }; + +}Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +1
-0@@ -0,0 +1,62 @@ +* AC timing parameters of DDR memories for a given speed-bin
Quoted 8 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt line 6
Quoted 5 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +5
-0+ At the moment properties for only LPDDR2 and DDR3 have been added + +Required properties: +- min-freq : minimum DDR clock frequency for the speed-bin +- max-freq : maximum DDR clock frequency for the speed-binThere should be a compatible field here too, especially if the binding ever has to be revised.
Ok. Bindings may have to be extended while adapting for other controllers.
Quoted 16 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt line 18
Quoted 13 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +12
-0+ +Optional properties: + +The following properties represent AC timing parameters from the memory +data-sheet of the device for a given speed-bin. All these properties are +of type<u32> and "-ps", "-ns", "-nCK" etc in the name indicates the +unit of the corresponding parameter: + ps - pico seconds + ns - nano seconds + nCK - number of DDR clock cycles. Please note that in LPDDR2 spec and + data-sheets tCK is used inter-changeably for nCK. Both are equivalent + in this context.Seems noisy to include the units on every single property instead of just in the bindings.
Hmm.. How about having them only for the exceptions below, that is, "nCK" and "ns" so that people don't make avoidable mistakes while entering the data.
Quoted 23 lines
Quoted 12 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +11
-0+ +- tRCD-ps +- tWR-ps +- tRAS-min-ps +- tRRD-ps +- tWTR-ps +- tXP-ps +- tRTP-ps +- tDQSCK-max-ps +- tFAW-ps +- tZQCS-psDocumentation/devicetree/bindings/ddr/ddr_timings.txt line 39
Quoted 10 lines
Documentation/devicetree/bindings/ddr/ddr_timings.txt new file +10
-0+- tZQinit-ps +- tRP-ps /* DDR3 only */ +- tRC-ps /* DDR3 only */ +- tXSDLL-nCK /* DDR3 only */ +- tCKE-ps /* DDR3 only */ +- tZQoper-ps /* DDR3 only */ +- tRPab-ps /* LPDDR2 only */ +- tZQCL-ps /* LPDDR2 only */ +- tCKESR-ps /* LPDDR2 only */ +- tRAS-max-ns /* LPDDR2 only */
Quoted 1 line
Same above about type-specific properties.
Explained above.
Thanks for the review.
best regards,
Aneesh
RFC PATCH v2 1/3 dt: device tree bindings for DDR memories
Hi Olof,
Quoted 9 lines · Aneesh V
Hi Olof,
Quoted 6 lines · Olof Johansson
Hi,
Some comments below, but also a more general question: How much of this generic data makes sense to encode in the device tree? Final hardware configuration usually has to take into consideration board layout/signal delays, etc, and that's not part of this binding.
When I was looking at your comments again for fixing them, I just realized that I hadn't answered part of this question. In the recent OMAPs, memory chips are stacked on to the OMAP, hence board layout etc doesn't figure in the equation. The only board level details that we need to program the memory controller are the details about the memory device itself, which is what this binding is targeting.
Quoted 10 lines
The JEDEC specifies base values for all timing parameters. But Vendors can improve on these timings and provide better values. Using device specific timing values therefore provides scope for optimization.
Everything that I have encoded here is needed by our driver to re-configure our SDRAM controller during DVFS. In fact, I have not listed all AC timing parameters in the spec in this binding, leaving the rest for future users to add if they need them.
br,
Aneesh
PATCH v2 1/3 dt: device tree bindings for DDR memories
In reply to Aneesh Vdevice tree bindings for DDR SDRAM memories compliant to JEDEC standards. Currently only DDR3 and LPDDR2 have been considered for this binding. Properties for other memory types(DDR2 etc) could be added to this binding on a need-basis.
The 'ddr' binding in-turn uses another binding 'ddr-timings' for specifying the AC timing parameters of the memory device at different speed-bins.
Changes in RFC v2:
* Removed the "manufacturer" property and added it in compatible property instead
* Changed the DDR device names in example to indicate the part number
--- .../devicetree/bindings/ddr/lpddr2-timings.txt | 50 +++++++++ Documentation/devicetree/bindings/ddr/lpddr2.txt | 106 ++++++++++++++++++++ 2 files changed, 156 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/ddr/lpddr2-timings.txt create mode 100644 Documentation/devicetree/bindings/ddr/lpddr2.txt
Documentation/devicetree/bindings/ddr/lpddr2-timings.txt new file +50 -0
@@ -0,0 +1,50 @@ +* AC timing parameters of LPDDR2(JESD209-2) memories for a given speed-bin + +Required properties: +- compatible : Should be "jedec,lpddr2-timings" +- min-freq : minimum DDR clock frequency for the speed-bin +- max-freq : maximum DDR clock frequency for the speed-bin + +Optional properties: + +The following properties represent AC timing parameters from the memory +data-sheet of the device for a given speed-bin. All these properties are +of type <u32> and the default unit is ps (pico seconds). +- tRCD +- tWR +- tRAS-min +- tRRD +- tWTR +- tXP +- tRTP +- tDQSCK-max +- tFAW +- tZQCS +- tZQinit +- tRPab +- tZQCL +- tCKESR +- tRAS-max-ns + +Example: + +timings_elpida_ECB240ABACN_400mhz: lpddr2-timings at 0 { + compatible = "jedec,lpddr2-timings"; + min-freq = <10000000>; + max-freq = <400000000>; + tRPab = <21000>; + tRCD = <18000>; + tWR = <15000>; + tRAS-min = <42000>; + tRRD = <10000>; + tWTR = <7500>; + tXP = <7500>; + tRTP = <7500>; + tCKESR = <15000>; + tDQSCK-max = <5500>; + tFAW = <50000>; + tZQCS = <90000>; + tZQCL = <360000>; + tZQinit = <1000000>; + tRAS-max-ns = <70000>; +};
Documentation/devicetree/bindings/ddr/lpddr2.txt new file +106 -0
106 lines not on this page · raw message
Signature · 1 line
1.7.1
RFC PATCH v2 2/3 dt: device tree bindings for TI's EMIF sdram controller
In reply to Aneesh VEMIF - External Memory Interface - is an SDRAM controller used in TI SoCs. EMIF supports, based on the IP revision, one or more of DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance of the EMIF IP and memory parts attached to it.
--- .../bindings/memory-controllers/ti/emif.txt | 64 ++++++++++++++++++++ 1 files changed, 64 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt new file +64 -0
@@ -0,0 +1,64 @@ +* EMIF family of TI SDRAM controllers + +EMIF - External Memory Interface - is an SDRAM controller used in +TI SoCs. EMIF supports, based on the IP revision, one or more of +DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance +of the EMIF IP and memory parts attached to it. + +Required properties: +- compatible : One or more of "ti,emif-ddr2", "ti,emif-ddr3", and + "ti,emif-lpddr2" + + "ti,emif-ddr2" should be listed of the EMIF controller on this SoC + supports DDR2 memories + + "ti,emif-ddr3" should be listed of the EMIF controller on this SoC + supports DDR3 memories + + "ti,emif-lpddr2" should be listed of the EMIF controller on this SoC + supports LPDDR2 memories + +- ti,hwmods : For TI hwmods processing and omap device creation + the value shall be "emif<n>" where <n> is the number of the EMIF + instance with base 1. + +- phy-type : string indicating the phy type. Should be one of the + following: + + "phy-type-omap4" : PHY used in OMAP4 family of SoCs + + "phy-type-dm81xx" : PHY used in DM81XX family of SoCs + +- ddr-handle : phandle to a "ddr" node representing the memory part + attached to this EMIF instance. + +Optional properties: +- cs1-used : Have this property if CS1 of this EMIF + instance has a memory part attached to it. If there is a memory + part attached to CS1, it should be the same type as the one on CS0, + so there is no need to give the details of this memory part. + +- cal-resistor-per-cs : Have this property if the board has one + calibration resistor per chip-select. + +- hw-caps-read-idle-ctrl: Have this property if the controller + supports read idle window programming + +- hw-caps-ll-interface : Have this property if the controller + has a low latency interface and corresponding interrupt events + +- hw-caps-temp-alert : Have this property if the controller + has capability for generating SDRAM temperature alerts + +Example: + +emif1: emif at 0x4c000000 { + compatible = "ti,emif-lpddr2"; + ti,hwmods = "emif2"; + phy-type = "phy-type-omap4"; + ddr-handle = <&elpida_ECB240ABACN>; + cs1-used; + hw-caps-read-idle-ctrl; + hw-caps-ll-interface; + hw-caps-temp-alert; +};
Signature · 1 line
1.7.1
RFC PATCH v2 2/3 dt: device tree bindings for TI's EMIF sdram controller
Hi,
Fewer comments here. :) But see below.
Quoted 26 lines · Aneesh V
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt new file +23
-0@@ -0,0 +1,64 @@ +* EMIF family of TI SDRAM controllers + +EMIF - External Memory Interface - is an SDRAM controller used in +TI SoCs. EMIF supports, based on the IP revision, one or more of +DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance +of the EMIF IP and memory parts attached to it. + +Required properties: +- compatible ? : One or more of "ti,emif-ddr2", "ti,emif-ddr3", and + ?"ti,emif-lpddr2" + + ?"ti,emif-ddr2" should be listed of the EMIF controller on this SoC + ?supports DDR2 memories + + ?"ti,emif-ddr3" should be listed of the EMIF controller on this SoC + ?supports DDR3 memories + + ?"ti,emif-lpddr2" should be listed of the EMIF controller on this SoC + ?supports LPDDR2 memories + +- ti,hwmods ? ?: For TI hwmods processing and omap device creation + ?the value shall be "emif<n>" where <n> is the number of the EMIF + ?instance with base 1.
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt line 33
Quoted 10 lines
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt new file +10
-0+ +- phy-type ? ? : string indicating the phy type. Should be one of the + ?following: + + ?"phy-type-omap4" ?: PHY used in OMAP4 family of SoCs + + ?"phy-type-dm81xx" : PHY used in DM81XX family of SoCs + +- ddr-handle ? : phandle to a "ddr" node representing the memory part + ?attached to this EMIF instance.
Just specify said ddr node as a child of this node instead of give it a handle. What other bus would the ddr node sit on, if not the memory controller bus?
-Olof
RFC PATCH v2 2/3 dt: device tree bindings for TI's EMIF sdram controller
Quoted 39 lines · Olof Johansson
Hi,
Fewer comments here. :) But see below.
Quoted 32 lines · Aneesh V
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt new file +29
-0@@ -0,0 +1,64 @@ +* EMIF family of TI SDRAM controllers + +EMIF - External Memory Interface - is an SDRAM controller used in +TI SoCs. EMIF supports, based on the IP revision, one or more of +DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance +of the EMIF IP and memory parts attached to it. + +Required properties: +- compatible : One or more of "ti,emif-ddr2", "ti,emif-ddr3", and + "ti,emif-lpddr2" + + "ti,emif-ddr2" should be listed of the EMIF controller on this SoC + supports DDR2 memories + + "ti,emif-ddr3" should be listed of the EMIF controller on this SoC + supports DDR3 memories + + "ti,emif-lpddr2" should be listed of the EMIF controller on this SoC + supports LPDDR2 memories + +- ti,hwmods : For TI hwmods processing and omap device creation + the value shall be "emif<n>" where<n> is the number of the EMIF + instance with base 1. + +- phy-type : string indicating the phy type. Should be one of the + following: + + "phy-type-omap4" : PHY used in OMAP4 family of SoCs +
Quoted 8 lines
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt line 33
Quoted 4 lines
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt new file +4
-0+ "phy-type-dm81xx" : PHY used in DM81XX family of SoCs + +- ddr-handle : phandle to a "ddr" node representing the memory part + attached to this EMIF instance.Just specify said ddr node as a child of this node instead of give it a handle. What other bus would the ddr node sit on, if not the memory controller bus?
We have two SDRAM controller instances and two separate channels. Typically, the two channels will have same type of memory attached. I did this avoid duplication of data. Is that fine?
thanks,
Aneesh
RFC PATCH v2 2/3 dt: device tree bindings for TI's EMIF sdram controller
In reply to Aneesh VOh wait, when I saw 3/3 I realized the following too:
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
Quoted 6 lines · Aneesh V
+- phy-type ? ? : string indicating the phy type. Should be one of the
+ ?following:Documentation/devicetree/bindings/memory-controllers/ti/emif.txt new file +4
-0+ + ?"phy-type-omap4" ?: PHY used in OMAP4 family of SoCs + + ?"phy-type-dm81xx" : PHY used in DM81XX family of SoCs
No, again please don't define new string properties when a simple binary property will do just fine. Just use "phy-type-omap4" or "phy-type-dm81xx" as an empty property to indicate what phy is used. Or encode as an integer and list the valid values here.
Every time you add a string to the device tree, the data structure grows, not to mention the fact that it adds a lot of string comparisons during setup. Please keep that in mind when defining bindings.
-Olof
RFC PATCH v2 2/3 dt: device tree bindings for TI's EMIF sdram controller
Quoted 4 lines · Olof Johansson
Oh wait, when I saw 3/3 I realized the following too:
On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V<[email protected]> wrote:
Quoted 11 lines
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt line 30
Quoted 6 lines
+- phy-type : string indicating the phy type. Should be one of the
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt new file +5
-0+ following: + + "phy-type-omap4" : PHY used in OMAP4 family of SoCs + + "phy-type-dm81xx" : PHY used in DM81XX family of SoCsNo, again please don't define new string properties when a simple binary property will do just fine. Just use "phy-type-omap4" or "phy-type-dm81xx" as an empty property to indicate what phy is used. Or encode as an integer and list the valid values here.
Ok. I just got carried away by readability. Somebody told me that something like #define will come to device-tree soon. Probably, I can use that then.
Is binary property suitable in situations like this where "one and only one" phy-type should be specified by the user?
Quoted 5 lines
Every time you add a string to the device tree, the data structure grows, not to mention the fact that it adds a lot of string comparisons during setup. Please keep that in mind when defining bindings.
Understand.
Thanks,
Aneesh
v2 cover dt: device tree bindings and data for EMIF and DDR
In reply to Aneesh VQuoted 10 lines · Aneesh V
This is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future.
The second patch provides the bindings for the EMIF controller.
Quoted 8 lines
The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards.
Thanks to Rajendra for answering my numerous queries on device tree.
This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version.
There's already a standard way (i.e. JEDEC standard) to define DDR chip configuration that's called SPD. Why invent something new? While this is normally an i2c eeprom on a DIMM, there's no reason you couldn't get it from somewhere else including perhaps the DT. There's already code in u-boot that can parse SPD data.
In general, is it really feasible to parse the DTB before DDR is initialized?
Rob
v2 cover dt: device tree bindings and data for EMIF and DDR
Quoted 20 lines · Rob Herring
Quoted 10 lines · Aneesh V
This is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future.
The second patch provides the bindings for the EMIF controller.
Quoted 8 lines
The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards.
Thanks to Rajendra for answering my numerous queries on device tree.
This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version.
Quoted 5 lines
There's already a standard way (i.e. JEDEC standard) to define DDR chip configuration that's called SPD. Why invent something new? While this is normally an i2c eeprom on a DIMM, there's no reason you couldn't get it from somewhere else including perhaps the DT. There's already code in u-boot that can parse SPD data.
I agree generic JEDEC standard would be good for the DT.
Quoted 2 lines
In general, is it really feasible to parse the DTB before DDR is initialized?
Changing timings is still needed for DVFS during runtime.
But we can boot to userspace with bootloader set timings, so I'm thinking that maybe these timings should be just set by loadable modules. Just the configuration of which timings to select should be passed via DT. Something in compatible like:
.compatible = "ti,omap3630", "sdram-micron-mt46h32m32lf-6";
And that should allow the SDRC driver to only accept timings for "sdram-micron-mt46h32m32lf-6".
Regards,
Tony
v2 cover dt: device tree bindings and data for EMIF and DDR
Quoted 21 lines · Tony Lindgren
Quoted 20 lines · Rob Herring
Quoted 18 lines · Aneesh V
This is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future.
The second patch provides the bindings for the EMIF controller.
The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards.
Thanks to Rajendra for answering my numerous queries on device tree.
This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version.
Quoted 7 lines
Quoted 5 lines
There's already a standard way (i.e. JEDEC standard) to define DDR chip configuration that's called SPD. Why invent something new? While this is normally an i2c eeprom on a DIMM, there's no reason you couldn't get it from somewhere else including perhaps the DT. There's already code in u-boot that can parse SPD data.
I agree generic JEDEC standard would be good for the DT.
Please see my comments in reply to Rob's mail. SPD doesn't seems to have a standard for LPDDR2. What JEDEC has now is not suitable for our needs.
Quoted 7 lines
Quoted 3 lines
In general, is it really feasible to parse the DTB before DDR is initialized?
Changing timings is still needed for DVFS during runtime.
But we can boot to userspace with bootloader set timings, so I'm
As far as I understand, in the current out-of-tree DVFS implementation for OMAP, DVFS can start even before user-space.
Quoted 8 lines
thinking that maybe these timings should be just set by loadable modules. Just the configuration of which timings to select should be passed via DT. Something in compatible like:
.compatible = "ti,omap3630", "sdram-micron-mt46h32m32lf-6";And that should allow the SDRC driver to only accept timings for "sdram-micron-mt46h32m32lf-6".
Do you mean one module per memory device and have all timing data in the respective module? Wouldn't this clutter the kernel proper with all these tables. By having the timing data in DT, it can be eventually moved out of kernel eventually, right?
br,
Aneesh
v2 cover dt: device tree bindings and data for EMIF and DDR
Hi Aneesh,
Quoted 38 lines · Aneesh V
Quoted 21 lines · Tony Lindgren
Quoted 20 lines · Rob Herring
Quoted 18 lines · Aneesh V
This is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future.
The second patch provides the bindings for the EMIF controller.
The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards.
Thanks to Rajendra for answering my numerous queries on device tree.
This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version.
Quoted 7 lines
Quoted 5 lines
There's already a standard way (i.e. JEDEC standard) to define DDR chip configuration that's called SPD. Why invent something new? While this is normally an i2c eeprom on a DIMM, there's no reason you couldn't get it from somewhere else including perhaps the DT. There's already code in u-boot that can parse SPD data.
I agree generic JEDEC standard would be good for the DT.
Please see my comments in reply to Rob's mail. SPD doesn't seems to have a standard for LPDDR2. What JEDEC has now is not suitable for our needs.
Quoted 4 lines
Quoted 3 lines
In general, is it really feasible to parse the DTB before DDR is initialized?
Quoted 6 lines
Quoted 3 lines
Changing timings is still needed for DVFS during runtime.
But we can boot to userspace with bootloader set timings, so I'm
As far as I understand, in the current out-of-tree DVFS implementation for OMAP, DVFS can start even before user-space.
Maybe it is the case, but that does not mean it should.
We can potentially delay the DVFS init until the user-space is started. This should not be considered as a big constraint.
Quoted 6 lines
Quoted 6 lines
thinking that maybe these timings should be just set by loadable modules. Just the configuration of which timings to select should be passed via DT. Something in compatible like:
.compatible = "ti,omap3630", "sdram-micron-mt46h32m32lf-6";
Quoted 7 lines
Quoted 2 lines
And that should allow the SDRC driver to only accept timings for "sdram-micron-mt46h32m32lf-6".
Do you mean one module per memory device and have all timing data in the respective module? Wouldn't this clutter the kernel proper with all these tables. By having the timing data in DT, it can be eventually moved out of kernel eventually, right?
Yes, that's the theory, but referring to Olof's point, this is not necessarily the goal of DT to store all the information that are not board dependent.
In this case, each DDR will have it sets of well known AC timings data that will never depend of the board config. In this case, storing that inside DT might not be the best solution.
In fact we always had the same kind of discussion for the pinmux data and for the clock data...
The conclusion being that most of the static data does not have to be in the DTS.
But since Linus was complaining about the huge amount of data inside the kernel, it is not obvious what the best solution is:-)
Regards,
Benoit
v2 cover dt: device tree bindings and data for EMIF and DDR
Hi Benoit
Quoted 2 lines · Benoit
Hi Aneesh,
<snip>
Quoted 35 lines
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
In general, is it really feasible to parse the DTB before DDR is initialized?
Changing timings is still needed for DVFS during runtime.
But we can boot to userspace with bootloader set timings, so I'm
As far as I understand, in the current out-of-tree DVFS implementation for OMAP, DVFS can start even before user-space.
Maybe it is the case, but that does not mean it should.
We can potentially delay the DVFS init until the user-space is started. This should not be considered as a big constraint.Quoted 6 lines
Quoted 6 lines
thinking that maybe these timings should be just set by loadable modules. Just the configuration of which timings to select should be passed via DT. Something in compatible like:
.compatible = "ti,omap3630", "sdram-micron-mt46h32m32lf-6";
Quoted 7 lines
Quoted 2 lines
And that should allow the SDRC driver to only accept timings for "sdram-micron-mt46h32m32lf-6".
Do you mean one module per memory device and have all timing data in the respective module? Wouldn't this clutter the kernel proper with all these tables. By having the timing data in DT, it can be eventually moved out of kernel eventually, right?
Yes, that's the theory, but referring to Olof's point, this is not necessarily the goal of DT to store all the information that are not board dependent.
In this case, each DDR will have it sets of well known AC timings data that will never depend of the board config. In this case, storing that inside DT might not be the best solution.
Quoted 7 lines
In fact we always had the same kind of discussion for the pinmux data and for the clock data...
The conclusion being that most of the static data does not have to be in the DTS.
But since Linus was complaining about the huge amount of data inside the kernel, it is not obvious what the best solution is:-)
Hmm.. I get the point now. Linus' complaint is what I had in mind too. My humble opinion is to have such data in DTS but re-use it as much as possible. That is, we could have something like a "sdram-micron- mt46h32m32lf-6.dtsi"(as you suggested before) that can be included by board level DTS files. I think the fact that dts files are organized at arch level today is limiting such re-use. Please correct me if I am wrong.
br,
Aneesh
v2 cover dt: device tree bindings and data for EMIF and DDR
Hi,
Quoted 51 lines · Aneesh V
Hi Benoit
Quoted 2 lines · Benoit
Hi Aneesh,
<snip>
Quoted 35 lines
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
In general, is it really feasible to parse the DTB before DDR is initialized?
Changing timings is still needed for DVFS during runtime.
But we can boot to userspace with bootloader set timings, so I'm
As far as I understand, in the current out-of-tree DVFS implementation for OMAP, DVFS can start even before user-space.
Maybe it is the case, but that does not mean it should.
We can potentially delay the DVFS init until the user-space is started. This should not be considered as a big constraint.Quoted 6 lines
Quoted 6 lines
thinking that maybe these timings should be just set by loadable modules. Just the configuration of which timings to select should be passed via DT. Something in compatible like:
.compatible = "ti,omap3630", "sdram-micron-mt46h32m32lf-6";
Quoted 7 lines
Quoted 2 lines
And that should allow the SDRC driver to only accept timings for "sdram-micron-mt46h32m32lf-6".
Do you mean one module per memory device and have all timing data in the respective module? Wouldn't this clutter the kernel proper with all these tables. By having the timing data in DT, it can be eventually moved out of kernel eventually, right?
Yes, that's the theory, but referring to Olof's point, this is not necessarily the goal of DT to store all the information that are not board dependent.
In this case, each DDR will have it sets of well known AC timings data that will never depend of the board config. In this case, storing that inside DT might not be the best solution.Quoted 7 lines
In fact we always had the same kind of discussion for the pinmux data and for the clock data...
The conclusion being that most of the static data does not have to be in the DTS.
But since Linus was complaining about the huge amount of data inside the kernel, it is not obvious what the best solution is:-)
Quoted 7 lines
Hmm.. I get the point now. Linus' complaint is what I had in mind too. My humble opinion is to have such data in DTS but re-use it as much as possible. That is, we could have something like a "sdram-micron- mt46h32m32lf-6.dtsi"(as you suggested before) that can be included by board level DTS files. I think the fact that dts files are organized at arch level today is limiting such re-use. Please correct me if I am wrong.
Gentle reminder on this one. Are we aligned on having the DDR timings in device tree?
br,
Aneesh
v2 cover dt: device tree bindings and data for EMIF and DDR
Hi,
Quoted 30 lines · Aneesh V
Hi,
Quoted 26 lines · Aneesh V
Hi Benoit
Quoted 3 lines · Benoit
Hi Aneesh,
<snip>
Quoted 16 lines
Quoted 11 lines
Quoted 7 lines
Quoted 2 lines
In general, is it really feasible to parse the DTB before DDR is initialized?
Changing timings is still needed for DVFS during runtime.
But we can boot to userspace with bootloader set timings, so I'm
As far as I understand, in the current out-of-tree DVFS implementation for OMAP, DVFS can start even before user-space.
Maybe it is the case, but that does not mean it should.
We can potentially delay the DVFS init until the user-space is started. This should not be considered as a big constraint.
Or at least until ramdisk is available, and store the tables there. It's a matter of seconds, delaying DVFS initialization until then shouldn't be the end of the world.
Quoted 42 lines
Quoted 33 lines
Quoted 24 lines
Quoted 7 lines
Quoted 7 lines
thinking that maybe these timings should be just set by loadable modules. Just the configuration of which timings to select should be passed via DT. Something in compatible like:
.compatible = "ti,omap3630", "sdram-micron-mt46h32m32lf-6";
Quoted 8 lines
Quoted 2 lines
And that should allow the SDRC driver to only accept timings for "sdram-micron-mt46h32m32lf-6".
Do you mean one module per memory device and have all timing data in the respective module? Wouldn't this clutter the kernel proper with all these tables. By having the timing data in DT, it can be eventually moved out of kernel eventually, right?
Yes, that's the theory, but referring to Olof's point, this is not necessarily the goal of DT to store all the information that are not board dependent.
In this case, each DDR will have it sets of well known AC timings data that will never depend of the board config. In this case, storing that inside DT might not be the best solution.Quoted 7 lines
In fact we always had the same kind of discussion for the pinmux data and for the clock data...
The conclusion being that most of the static data does not have to be in the DTS.
But since Linus was complaining about the huge amount of data inside the kernel, it is not obvious what the best solution is:-)Quoted 7 lines
Hmm.. I get the point now. Linus' complaint is what I had in mind too. My humble opinion is to have such data in DTS but re-use it as much as possible. That is, we could have something like a "sdram-micron- mt46h32m32lf-6.dtsi"(as you suggested before) that can be included by board level DTS files. I think the fact that dts files are organized at arch level today is limiting such re-use. Please correct me if I am wrong.
Quoted 2 lines
Gentle reminder on this one. Are we aligned on having the DDR timings in device tree?
I didn't revisit the thread until today, unfortunately, but the approach suggested by Tony sounds quite intriguing: Only encode the memory chip id, and have the driver request firmware (not a module) for that model that contains the SPD (if it isn't provided by the memory module itself, which it rarely is on embedded platforms). That data can then be parsed by the kernel like regular SPD.
As a second-best option, encoding in SPD format in the device-tree through dtsi files sounds like a reasonable approach: the format is already standardized and drivers who can already deal with i2c-based SPD data can just use it (with some minor changes).
-Olof
v2 cover dt: device tree bindings and data for EMIF and DDR
Hi Olof,
Quoted 30 lines · Olof Johansson
Hi,
Quoted 27 lines · Aneesh V
Hi,
Quoted 23 lines · Aneesh V
Hi Benoit
Quoted 3 lines · Benoit
Hi Aneesh,
<snip>
Quoted 13 lines
Quoted 11 lines
Quoted 7 lines
Quoted 2 lines
In general, is it really feasible to parse the DTB before DDR is initialized?
Changing timings is still needed for DVFS during runtime.
But we can boot to userspace with bootloader set timings, so I'm
As far as I understand, in the current out-of-tree DVFS implementation for OMAP, DVFS can start even before user-space.
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Maybe it is the case, but that does not mean it should.
We can potentially delay the DVFS init until the user-space is started. This should not be considered as a big constraint.Or at least until ramdisk is available, and store the tables there. It's a matter of seconds, delaying DVFS initialization until then shouldn't be the end of the world.
It's not about power savings, here is what I understand from discussion with power management folks. In our current architecture drivers can set frequency constraints with clock framework and this may in turn initiate frequency scaling and this can happen before user space. Perhaps we could forbid this too. But I am not sure if the benefit is worth the trouble.
Quoted 53 lines
Quoted 43 lines
Quoted 34 lines
Quoted 25 lines
Quoted 8 lines
Quoted 8 lines
thinking that maybe these timings should be just set by loadable modules. Just the configuration of which timings to select should be passed via DT. Something in compatible like:
.compatible = "ti,omap3630", "sdram-micron-mt46h32m32lf-6";
Quoted 8 lines
Quoted 2 lines
And that should allow the SDRC driver to only accept timings for "sdram-micron-mt46h32m32lf-6".
Do you mean one module per memory device and have all timing data in the respective module? Wouldn't this clutter the kernel proper with all these tables. By having the timing data in DT, it can be eventually moved out of kernel eventually, right?
Yes, that's the theory, but referring to Olof's point, this is not necessarily the goal of DT to store all the information that are not board dependent.
In this case, each DDR will have it sets of well known AC timings data that will never depend of the board config. In this case, storing that inside DT might not be the best solution.Quoted 7 lines
In fact we always had the same kind of discussion for the pinmux data and for the clock data...
The conclusion being that most of the static data does not have to be in the DTS.
But since Linus was complaining about the huge amount of data inside the kernel, it is not obvious what the best solution is:-)Quoted 7 lines
Hmm.. I get the point now. Linus' complaint is what I had in mind too. My humble opinion is to have such data in DTS but re-use it as much as possible. That is, we could have something like a "sdram-micron- mt46h32m32lf-6.dtsi"(as you suggested before) that can be included by board level DTS files. I think the fact that dts files are organized at arch level today is limiting such re-use. Please correct me if I am wrong.
Quoted 2 lines
Gentle reminder on this one. Are we aligned on having the DDR timings in device tree?
I didn't revisit the thread until today, unfortunately, but the approach suggested by Tony sounds quite intriguing: Only encode the memory chip id, and have the driver request firmware (not a module) for that model that contains the SPD (if it isn't provided by the memory module itself, which it rarely is on embedded platforms). That data can then be parsed by the kernel like regular SPD.
Quoted 4 lines
As a second-best option, encoding in SPD format in the device-tree through dtsi files sounds like a reasonable approach: the format is already standardized and drivers who can already deal with i2c-based SPD data can just use it (with some minor changes).
I did look for an SPD spec for LPDDR2, but couldn't find one. It appears to me that SPD is not used in LPDDR2 devices and therefore there is no standard governing it. I checked the DDR3 spec too. But that doesn't seem to have some parameters needed by our controller.
Even if SPD worked, I wonder if that is the right solution for our need. Don't you think it will be too cryptic for the user to input and verify the data (some of the bytes in the layout are a combination of more than one parameter). It's all fine if it came from the memory device. But when we have to enter it manually, can't we chose a more readable representation?
We wish to drop the DDR3 support because we have concluded that our platforms with DDR3 memories will not scale DDR frequency due to limitations in DDR3 protocol(operating frequency can vary only in a small range). So, is it ok to persist with my bindings for LPDDR2 (fixing the comments already given by you) and drop the DDR3 part from it?
br,
Aneesh
v2 cover dt: device tree bindings and data for EMIF and DDR
Quoted 51 lines · Aneesh V
Hi Olof,
Quoted 37 lines · Olof Johansson
Hi,
Quoted 33 lines · On Sun, Jan 8, 2012 at 9:23 AM, Aneesh V<[email protected]> ?wrote:
Hi,
Quoted 28 lines · Aneesh V
Hi Benoit
Quoted 4 lines · Benoit
Hi Aneesh,
<snip>
Quoted 16 lines
Quoted 13 lines
Quoted 8 lines
Quoted 2 lines
In general, is it really feasible to parse the DTB before DDR is initialized?
Changing timings is still needed for DVFS during runtime.
But we can boot to userspace with bootloader set timings, so I'm
As far as I understand, in the current out-of-tree DVFS implementation for OMAP, DVFS can start even before user-space.
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Maybe it is the case, but that does not mean it should.
We can potentially delay the DVFS init until the user-space is started. This should not be considered as a big constraint.Or at least until ramdisk is available, and store the tables there. It's a matter of seconds, delaying DVFS initialization until then shouldn't be the end of the world.
Quoted 6 lines
It's not about power savings, here is what I understand from discussion with power management folks. In our current architecture drivers can set frequency constraints with clock framework and this may in turn initiate frequency scaling and this can happen before user space. Perhaps we could forbid this too. But I am not sure if the benefit is worth the trouble.
Jumping through these kinds of hoops causes me to really question what it is we're trying to achieve. There is already the case where clock event code needs statically allocated clocks for setup before DT data is available, and in this example at least some subset of mem timings must be done in bootloader prior to DT data availability again. Some times these situations are unavoidable, but I feel uneasy about splitting data up across multiple sources. Hunting bugs in such data is going to be painful.
And delaying DVFS (at least for the parts affecting mem) until userspace is loaded doesn't seem great to me either. We're basically pushing back feature readiness (with respect to boot sequence) in the name of organizing data in a pretty way... but it's not a pretty solution since the data will have to be "split" as shown above.
Regards,
Mike
v2 cover dt: device tree bindings and data for EMIF and DDR
Hi,
Quoted 5 lines · Mike
And delaying DVFS (at least for the parts affecting mem) until userspace is loaded doesn't seem great to me either. ?We're basically pushing back feature readiness (with respect to boot sequence) in the name of organizing data in a pretty way... but it's not a pretty solution since the data will have to be "split" as shown above.
Ok, so let's put the JEDEC SPD data in the device tree then. But I fail to see how that changes the "split"? There's still two sources of configuration, one from firmware used at boot and one from a data structure that the kernel uses.
I do think sticking to an existing well-defined data structure such as SPD data is to be preferred over doing an open-coded new binding. This way, some platforms that might or might not have SPD in hardware can use the same code paths (i.e. a board that has memory on a DIMM instead of soldered down, or that uses soldered-down SPD).
-Olof
v2 cover dt: device tree bindings and data for EMIF and DDR
In reply to Aneesh VHi Olof,
Quoted 1 line · Aneesh V
Hi Olof,
<snip>
Quoted 6 lines
We wish to drop the DDR3 support because we have concluded that our platforms with DDR3 memories will not scale DDR frequency due to limitations in DDR3 protocol(operating frequency can vary only in a small range). So, is it ok to persist with my bindings for LPDDR2 (fixing the comments already given by you) and drop the DDR3 part from it?
Ping! Forgive my impatience, but I would like to close on this at the earliest to continue my work on the driver.
thanks,
Aneesh
v2 cover dt: device tree bindings and data for EMIF and DDR
In reply to Rob HerringQuoted 20 lines · Rob Herring
Quoted 10 lines · Aneesh V
This is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future.
The second patch provides the bindings for the EMIF controller.
Quoted 8 lines
The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards.
Thanks to Rajendra for answering my numerous queries on device tree.
This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version.
Quoted 5 lines
There's already a standard way (i.e. JEDEC standard) to define DDR chip configuration that's called SPD. Why invent something new? While this is normally an i2c eeprom on a DIMM, there's no reason you couldn't get it from somewhere else including perhaps the DT. There's already code in u-boot that can parse SPD data.
Thanks for pointing this out. I looked into this a bit. I see some difficulties in adopting SPD for our needs.
1. Our primary target is LPDDR2 and I can't seem to find an SPD standard for LPDDR2. Maybe, because automatic memory detection is not that critical in the embedded world.
2. I did find one for DDR SDRAM memories(Appendix D, Rev 1.0 - maybe for the first generation of PC DDR memories). But many of the AC timing parameters needed to program our controller are not listed in it.
3. We do not really need DDR3 support at the moment because we do not intend to scale DDR frequency in platforms with DDR3 memory. This is due the to limited operating frequency range of DDR3.
So, I was wondering whether I should limit the binding to only LPDDR2 and have an SPD based binding for DDR2/DDR3 if that is required later? What do you think?
Quoted 3 lines
In general, is it really feasible to parse the DTB before DDR is initialized?
As pointed out by Tony we rely on bootloader for the initial SDRAM configuration. The kernel SDRAM controller driver is used mainly for DVFS and thermal management.
best regards,
Aneesh
v2 cover dt: device tree bindings and data for EMIF and DDR
In reply to Aneesh VThis is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future.
The second patch provides the bindings for the EMIF controller.
The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards.
Thanks to Rajendra for answering my numerous queries on device tree.
This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version.
Aneesh V (3):
dt: device tree bindings for DDR memories
dt: device tree bindings for TI's EMIF sdram controller arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards
Documentation/devicetree/bindings/ddr/ddr.txt | 114 ++++++++++++++++++++ .../devicetree/bindings/ddr/ddr_timings.txt | 62 +++++++++++ .../bindings/memory-controllers/ti/emif.txt | 64 +++++++++++ arch/arm/boot/dts/omap-common-devices.dtsi | 63 +++++++++++ arch/arm/boot/dts/omap4-panda.dts | 13 +++ arch/arm/boot/dts/omap4-sdp.dts | 13 +++ arch/arm/boot/dts/omap4.dtsi | 19 ++++ 7 files changed, 348 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/ddr/ddr.txt create mode 100644 Documentation/devicetree/bindings/ddr/ddr_timings.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti/emif.txt create mode 100644 arch/arm/boot/dts/omap-common-devices.dtsi
v2 cover dt: device tree bindings and data for EMIF and DDR
Quoted 10 lines · Aneesh V
This is an RFC to add new device tree bindings for DDR memories and EMIF - TI's DDR SDRAM controller.
The first patch adds bindings for DDR memories. Currently, we have added properties for only DDR3 and LPDDR2 memories. However, the binding can be easily extended to describe other types such as DDR2 in the future.
The second patch provides the bindings for the EMIF controller.
Quoted 8 lines
The final patch provides DT data for EMIF controller instances in OMAP4 and LPDDR2 memories attached to them on various boards.
Thanks to Rajendra for answering my numerous queries on device tree.
This is a re-post of the RFC that was posted to devicetree-discuss ml, now sent to a larger audience and looping out an internal list. Please ignore the previous version.
Please ignore this series. I did git-send-email from wrong directory.
Quoted 19 lines
Aneesh V (3):
dt: device tree bindings for DDR memories
dt: device tree bindings for TI's EMIF sdram controller arm/dts: EMIF and lpddr2 device tree data for OMAP4 boardsDocumentation/devicetree/bindings/ddr/ddr.txt | 114 ++++++++++++++++++++ .../devicetree/bindings/ddr/ddr_timings.txt | 62 +++++++++++ .../bindings/memory-controllers/ti/emif.txt | 64 +++++++++++ arch/arm/boot/dts/omap-common-devices.dtsi | 63 +++++++++++ arch/arm/boot/dts/omap4-panda.dts | 13 +++ arch/arm/boot/dts/omap4-sdp.dts | 13 +++ arch/arm/boot/dts/omap4.dtsi | 19 ++++ 7 files changed, 348 insertions(+), 0 deletions(-)create mode 100644
Documentation/devicetree/bindings/ddr/ddr.txtcreate mode 100644Documentation/devicetree/bindings/ddr/ddr_timings.txtcreate mode 100644Documentation/devicetree/bindings/memory-controllers/ti/emif.txtcreate mode 100644arch/arm/boot/dts/omap-common-devices.dtsi
PATCH v2 2/3 dt: device tree bindings for TI's EMIF sdram controller
In reply to Aneesh VEMIF - External Memory Interface - is an SDRAM controller used in TI SoCs. EMIF supports, based on the IP revision, one or more of DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance of the EMIF IP and memory parts attached to it.
--- .../bindings/memory-controllers/ti/emif.txt | 62 ++++++++++++++++++++ 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt new file +62 -0
@@ -0,0 +1,62 @@ +* EMIF family of TI SDRAM controllers + +EMIF - External Memory Interface - is an SDRAM controller used in +TI SoCs. EMIF supports, based on the IP revision, one or more of +DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance +of the EMIF IP and memory parts attached to it. + +Required properties: +- compatible : One or more of "ti,emif-lpddr22", "ti,emif-lpddr23", and + "ti,emif-lpddr2" + + "ti,emif-lpddr22" should be listed of the EMIF controller on this SoC + supports DDR2 memories + + "ti,emif-lpddr23" should be listed of the EMIF controller on this SoC + supports DDR3 memories + + "ti,emif-lpddr2" should be listed of the EMIF controller on this SoC + supports LPDDR2 memories + +- ti,hwmods : For TI hwmods processing and omap device creation + the value shall be "emif<n>" where <n> is the number of the EMIF + instance with base 1. + +- phy-type : <u32> indicating the DDR phy type. Following are the + allowed values + <1> : Attila PHY + <2> : Intelli PHY + +- lpddr2-handle : phandle to a "lpddr2" node representing the memory part + attached to this EMIF instance. + +Optional properties: +- cs1-used : Have this property if CS1 of this EMIF + instance has a memory part attached to it. If there is a memory + part attached to CS1, it should be the same type as the one on CS0, + so there is no need to give the details of this memory part. + +- cal-resistor-per-cs : Have this property if the board has one + calibration resistor per chip-select. + +- hw-caps-read-idle-ctrl: Have this property if the controller + supports read idle window programming + +- hw-caps-ll-interface : Have this property if the controller + has a low latency interface and corresponding interrupt events + +- hw-caps-temp-alert : Have this property if the controller + has capability for generating SDRAM temperature alerts + +Example: + +emif1: emif at 0x4c000000 { + compatible = "ti,emif-lpddr2"; + ti,hwmods = "emif2"; + phy-type = <1>; + lpddr2-handle = <&elpida_ECB240ABACN>; + cs1-used; + hw-caps-read-idle-ctrl; + hw-caps-ll-interface; + hw-caps-temp-alert; +};
Signature · 1 line
1.7.1
RFC PATCH v2 3/3 arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards
In reply to Aneesh VDevice tree data for the EMIF sdram controllers in OMAP4 and DDR memories attached to OMAP4 boards.
--- arch/arm/boot/dts/omap-common-devices.dtsi | 63 ++++++++++++++++++++++++++++ arch/arm/boot/dts/omap4-panda.dts | 13 ++++++ arch/arm/boot/dts/omap4-sdp.dts | 13 ++++++ arch/arm/boot/dts/omap4.dtsi | 19 ++++++++ 4 files changed, 108 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/omap-common-devices.dtsi
arch/arm/boot/dts/omap-common-devices.dtsi new file +63 -0
@@ -0,0 +1,63 @@ +/* + * Common devices used in different OMAP boards + */ + +/ { + elpida_ECB240ABACN: ddr { + compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4"; + density = "2Gb"; + io-width = "x32"; + + tRPab-min-nCK = <3>; + tRCD-min-nCK = <3>; + tWR-min-nCK = <3>; + tRASmin-min-nCK = <3>; + tRRD-min-nCK = <2>; + tWTR-min-nCK = <2>; + tXP-min-nCK = <2>; + tRTP-min-nCK = <2>; + tCKE-min-nCK = <3>; + tCKESR-min-nCK = <3>; + tFAW-min-nCK = <8>; + + timings_elpida_ECB240ABACN_400mhz: ddr-timings at 1 { + min-freq = <10000000>; + max-freq = <400000000>; + tRPab-ps = <21000>; + tRCD-ps = <18000>; + tWR-ps = <15000>; + tRAS-min-ps = <42000>; + tRRD-ps = <10000>; + tWTR-ps = <7500>; + tXP-ps = <7500>; + tRTP-ps = <7500>; + tCKESR-ps = <15000>; + tDQSCK-max-ps = <5500>; + tFAW-ps = <50000>; + tZQCS-ps = <90000>; + tZQCL-ps = <360000>; + tZQinit-ps = <1000000>; + tRAS-max-ns = <70000>; + }; + + timings_elpida_ECB240ABACN_200mhz: ddr-timings@ { + min-freq = <10000000>; + max-freq = <200000000>; + tRPab-ps = <21000>; + tRCD-ps = <18000>; + tWR-ps = <15000>; + tRAS-min-ps = <42000>; + tRRD-ps = <10000>; + tWTR-ps = <10000>; + tXP-ps = <7500>; + tRTP-ps = <7500>; + tCKESR-ps = <15000>; + tDQSCK-max-ps = <5500>; + tFAW-ps = <50000>; + tZQCS-ps = <90000>; + tZQCL-ps = <360000>; + tZQinit-ps = <1000000>; + tRAS-max-ns = <70000>; + }; + }; +};
arch/arm/boot/dts/omap4-panda.dts +13 -0
@@ -8,6 +8,7 @@ /dts-v1/; /include/ "omap4.dtsi" +/include/ "omap-common-devices.dtsi" / { model = "TI OMAP4 PandaBoard";
@@ -26,4 +27,16 @@ device_type = "memory"; reg = <0x80000000 0x40000000>; /* 1 GB */ }; + + ocp { + emif1: emif at 0x4c000000 { + cs1-used; + ddr-handle = <&elpida_ECB240ABACN>; + }; + + emif2: emif at 0x4d000000 { + cs1-used; + ddr-handle = <&elpida_ECB240ABACN>; + }; + }; };
arch/arm/boot/dts/omap4-sdp.dts +13 -0
@@ -8,6 +8,7 @@ /dts-v1/; /include/ "omap4.dtsi" +/include/ "omap-common-devices.dtsi" / { model = "TI OMAP4 SDP board";
@@ -26,4 +27,16 @@ device_type = "memory"; reg = <0x80000000 0x40000000>; /* 1 GB */ }; + + ocp { + emif1: emif at 0x4c000000 { + cs1-used; + ddr-handle = <&elpida_ECB240ABACN>; + }; + + emif2: emif at 0x4d000000 { + cs1-used; + ddr-handle = <&elpida_ECB240ABACN>; + }; + }; };
arch/arm/boot/dts/omap4.dtsi +19 -0
@@ -99,5 +99,24 @@ reg = <0x48241000 0x1000>, <0x48240100 0x0100>; }; + + emif1: emif at 0x4c000000 { + compatible = "ti,emif-lpddr2"; + ti,hwmods = "emif1"; + phy-type = "phy-type-omap4"; + hw-caps-read-idle-ctrl; + hw-caps-ll-interface; + hw-caps-temp-alert; + }; + + emif2: emif at 0x4d000000 { + compatible = "ti,emif-lpddr2"; + ti,hwmods = "emif2"; + phy-type = "phy-type-omap4"; + hw-caps-read-idle-ctrl; + hw-caps-ll-interface; + hw-caps-temp-alert; + }; + }; };
Signature · 1 line
1.7.1
PATCH v2 3/3 arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards
In reply to Aneesh VDevice tree data for the EMIF sdram controllers in OMAP4 and DDR memories attached to OMAP4 boards.
--- arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 64 +++++++++++++++++++++++++++++ arch/arm/boot/dts/omap4-panda.dts | 13 ++++++ arch/arm/boot/dts/omap4-sdp.dts | 13 ++++++ arch/arm/boot/dts/omap4.dtsi | 19 +++++++++ 4 files changed, 109 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi
arch/arm/boot/dts/elpida_ecb240abacn.dtsi new file +64 -0
@@ -0,0 +1,64 @@ +/* + * Common devices used in different OMAP boards + */ + +/ { + elpida_ECB240ABACN: lpddr2 { + compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4"; + density = <2048>; + io-width = <32>; + + tRPab-min-tck = <3>; + tRCD-min-tck = <3>; + tWR-min-tck = <3>; + tRASmin-min-tck = <3>; + tRRD-min-tck = <2>; + tWTR-min-tck = <2>; + tXP-min-tck = <2>; + tRTP-min-tck = <2>; + tCKE-min-tck = <3>; + tCKESR-min-tck = <3>; + tFAW-min-tck = <8>; + + timings_elpida_ECB240ABACN_400mhz: lpddr2-timings at 0 { + compatible = "jedec,lpddr2-timings"; + min-freq = <10000000>; + max-freq = <400000000>; + tRPab = <21000>; + tRCD = <18000>; + tWR = <15000>; + tRAS-min = <42000>; + tRRD = <10000>; + tWTR = <7500>; + tXP = <7500>; + tRTP = <7500>; + tCKESR = <15000>; + tDQSCK-max = <5500>; + tFAW = <50000>; + tZQCS = <90000>; + tZQCL = <360000>; + tZQinit = <1000000>; + tRAS-max-ns = <70000>; + }; + + timings_elpida_ECB240ABACN_200mhz: lpddr2-timings at 1 { + min-freq = <10000000>; + max-freq = <200000000>; + tRPab = <21000>; + tRCD = <18000>; + tWR = <15000>; + tRAS-min = <42000>; + tRRD = <10000>; + tWTR = <10000>; + tXP = <7500>; + tRTP = <7500>; + tCKESR = <15000>; + tDQSCK-max = <5500>; + tFAW = <50000>; + tZQCS = <90000>; + tZQCL = <360000>; + tZQinit = <1000000>; + tRAS-max-ns = <70000>; + }; + }; +};
arch/arm/boot/dts/omap4-panda.dts +13 -0
@@ -8,6 +8,7 @@ /dts-v1/; /include/ "omap4.dtsi" +/include/ "elpida_ecb240abacn.dtsi" / { model = "TI OMAP4 PandaBoard";
@@ -26,4 +27,16 @@ device_type = "memory"; reg = <0x80000000 0x40000000>; /* 1 GB */ }; + + ocp { + emif1: emif at 0x4c000000 { + cs1-used; + lpddr2-handle = <&elpida_ECB240ABACN>; + }; + + emif2: emif at 0x4d000000 { + cs1-used; + lpddr2-handle = <&elpida_ECB240ABACN>; + }; + }; };
arch/arm/boot/dts/omap4-sdp.dts +13 -0
@@ -8,6 +8,7 @@ /dts-v1/; /include/ "omap4.dtsi" +/include/ "elpida_ecb240abacn.dtsi" / { model = "TI OMAP4 SDP board";
@@ -26,4 +27,16 @@ device_type = "memory"; reg = <0x80000000 0x40000000>; /* 1 GB */ }; + + ocp { + emif1: emif at 0x4c000000 { + cs1-used; + lpddr2-handle = <&elpida_ECB240ABACN>; + }; + + emif2: emif at 0x4d000000 { + cs1-used; + lpddr2-handle = <&elpida_ECB240ABACN>; + }; + }; };
arch/arm/boot/dts/omap4.dtsi +19 -0
@@ -127,5 +127,24 @@ ti,hwmods = "uart4"; clock-frequency = <48000000>; }; + + emif1: emif at 0x4c000000 { + compatible = "ti,emif-lpddr2"; + ti,hwmods = "emif1"; + phy-type = "phy-type-omap4"; + hw-caps-read-idle-ctrl; + hw-caps-ll-interface; + hw-caps-temp-alert; + }; + + emif2: emif at 0x4d000000 { + compatible = "ti,emif-lpddr2"; + ti,hwmods = "emif2"; + phy-type = <1>; + hw-caps-read-idle-ctrl; + hw-caps-ll-interface; + hw-caps-temp-alert; + }; + }; };
Signature · 1 line
1.7.1