[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[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.

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 v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[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.

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 v2 PATCH 1/3] dt: device tree bindings for DDR memories

[Aneesh V]

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.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
 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

diff --git a/Documentation/devicetree/bindings/ddr/ddr.txt b/Documentation/devicetree/bindings/ddr/ddr.txt
new file mode 100644
index 0000000..f15c4dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/ddr/ddr.txt
@@ -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>;
+	};
+
+}
diff --git a/Documentation/devicetree/bindings/ddr/ddr_timings.txt b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
new file mode 100644
index 0000000..38fcdec
--- /dev/null
+++ b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
@@ -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
+
+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.
+
+- tRCD-ps
+- tWR-ps
+- tRAS-min-ps
+- tRRD-ps
+- tWTR-ps
+- tXP-ps
+- tRTP-ps
+- tDQSCK-max-ps
+- tFAW-ps
+- tZQCS-ps
+- 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 */
+
+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

[RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories

[Aneesh V]

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.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
 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

diff --git a/Documentation/devicetree/bindings/ddr/ddr.txt b/Documentation/devicetree/bindings/ddr/ddr.txt
new file mode 100644
index 0000000..f15c4dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/ddr/ddr.txt
@@ -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>;
+	};
+
+}
diff --git a/Documentation/devicetree/bindings/ddr/ddr_timings.txt b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
new file mode 100644
index 0000000..38fcdec
--- /dev/null
+++ b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
@@ -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
+
+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.
+
+- tRCD-ps
+- tWR-ps
+- tRAS-min-ps
+- tRRD-ps
+- tWTR-ps
+- tXP-ps
+- tRTP-ps
+- tDQSCK-max-ps
+- tFAW-ps
+- tZQCS-ps
+- 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 */
+
+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

[RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[Aneesh V]

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.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
 .../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

diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
new file mode 100644
index 0000000..e2f687b
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -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@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;
+};
-- 
1.7.1

[RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[Aneesh V]

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.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
 .../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

diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
new file mode 100644
index 0000000..e2f687b
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -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;
+};
-- 
1.7.1

[RFC v2 PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards

[Aneesh V]

Device tree data for the EMIF sdram controllers in OMAP4
and DDR memories attached to OMAP4 boards.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
 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

diff --git a/arch/arm/boot/dts/omap-common-devices.dtsi b/arch/arm/boot/dts/omap-common-devices.dtsi
new file mode 100644
index 0000000..bac2a40
--- /dev/null
+++ b/arch/arm/boot/dts/omap-common-devices.dtsi
@@ -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@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>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index c702657..3446f4f 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -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@0x4c000000 {
+			cs1-used;
+			ddr-handle = <&elpida_ECB240ABACN>;
+		};
+
+		emif2: emif@0x4d000000 {
+			cs1-used;
+			ddr-handle = <&elpida_ECB240ABACN>;
+		};
+	};
 };
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..799ac0a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -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@0x4c000000 {
+			cs1-used;
+			ddr-handle = <&elpida_ECB240ABACN>;
+		};
+
+		emif2: emif@0x4d000000 {
+			cs1-used;
+			ddr-handle = <&elpida_ECB240ABACN>;
+		};
+	};
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..5393ae5 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -99,5 +99,24 @@
 			reg = <0x48241000 0x1000>,
 			      <0x48240100 0x0100>;
 		};
+
+		emif1: emif@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@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;
+		};
+
 	};
 };
-- 
1.7.1

[RFC v2 PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards

[Aneesh V]

Device tree data for the EMIF sdram controllers in OMAP4
and DDR memories attached to OMAP4 boards.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
 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

diff --git a/arch/arm/boot/dts/omap-common-devices.dtsi b/arch/arm/boot/dts/omap-common-devices.dtsi
new file mode 100644
index 0000000..bac2a40
--- /dev/null
+++ b/arch/arm/boot/dts/omap-common-devices.dtsi
@@ -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>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index c702657..3446f4f 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -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>;
+		};
+	};
 };
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..799ac0a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -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>;
+		};
+	};
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..5393ae5 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -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;
+		};
+
 	};
 };
-- 
1.7.1

Re: [RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories

[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.


On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V <aneesh@ti.com> wrote:

> diff --git a/Documentation/devicetree/bindings/ddr/ddr.txt b/Documentation/devicetree/bindings/ddr/ddr.txt
> new file mode 100644
> index 0000000..f15c4dd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ddr/ddr.txt
> @@ -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"

No, please encode as a two-cell integer instead.

> +- io-width : string representing the io width: "x8", "x16" or "x32".

No, encode as an integer.

> +
> +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.

> +
> +- 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 {

You will need a unit address here.

> +               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 {

Same here, since you have more than one table. See previous
discussions about emc tables on tegra (I'll repost that series this
week).

> +               min-freq        = <10000000>;
> +               max-freq        = <200000000>;
> +               tRP-ps          = <21000>;
> +               tRCD-ps         = <18000>;
> +               tWR-ps          = <15000>;
> +               tRAS-min-ps     = <42000:;

Typo

> +               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>;
> +       };
> +
> +}
> diff --git a/Documentation/devicetree/bindings/ddr/ddr_timings.txt b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
> new file mode 100644
> index 0000000..38fcdec
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
> @@ -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.

> +
> +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.

> +
> +- tRCD-ps
> +- tWR-ps
> +- tRAS-min-ps
> +- tRRD-ps
> +- tWTR-ps
> +- tXP-ps
> +- tRTP-ps
> +- tDQSCK-max-ps
> +- tFAW-ps
> +- tZQCS-ps
> +- 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.

> +
> +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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories

[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.


On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V <aneesh@ti.com> wrote:

> diff --git a/Documentation/devicetree/bindings/ddr/ddr.txt b/Documentation/devicetree/bindings/ddr/ddr.txt
> new file mode 100644
> index 0000000..f15c4dd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ddr/ddr.txt
> @@ -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"

No, please encode as a two-cell integer instead.

> +- io-width : string representing the io width: "x8", "x16" or "x32".

No, encode as an integer.

> +
> +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.

> +
> +- 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 {

You will need a unit address here.

> + ? ? ? ? ? ? ? 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 {

Same here, since you have more than one table. See previous
discussions about emc tables on tegra (I'll repost that series this
week).

> + ? ? ? ? ? ? ? min-freq ? ? ? ?= <10000000>;
> + ? ? ? ? ? ? ? max-freq ? ? ? ?= <200000000>;
> + ? ? ? ? ? ? ? tRP-ps ? ? ? ? ?= <21000>;
> + ? ? ? ? ? ? ? tRCD-ps ? ? ? ? = <18000>;
> + ? ? ? ? ? ? ? tWR-ps ? ? ? ? ?= <15000>;
> + ? ? ? ? ? ? ? tRAS-min-ps ? ? = <42000:;

Typo

> + ? ? ? ? ? ? ? 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>;
> + ? ? ? };
> +
> +}
> diff --git a/Documentation/devicetree/bindings/ddr/ddr_timings.txt b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
> new file mode 100644
> index 0000000..38fcdec
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
> @@ -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.

> +
> +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.

> +
> +- tRCD-ps
> +- tWR-ps
> +- tRAS-min-ps
> +- tRRD-ps
> +- tWTR-ps
> +- tXP-ps
> +- tRTP-ps
> +- tDQSCK-max-ps
> +- tFAW-ps
> +- tZQCS-ps
> +- 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.

> +
> +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

Re: [RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[Olof Johansson]

Hi,

Fewer comments here. :) But see below.

On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V <aneesh@ti.com> wrote:


> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> @@ -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.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[Olof Johansson]

Hi,

Fewer comments here. :) But see below.

On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V <aneesh@ti.com> wrote:


> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> @@ -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.

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

Re: [RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[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 <aneesh@ti.com> wrote:

> +- 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

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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[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 <aneesh@ti.com> wrote:

> +- 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

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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Rob Herring]

On 12/19/2011 08:05 AM, Aneesh V wrote:
> 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.

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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Rob Herring]

On 12/19/2011 08:05 AM, Aneesh V wrote:
> 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.

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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Tony Lindgren]

* Rob Herring <robherring2@gmail.com> [111219 14:29]:
> On 12/19/2011 08:05 AM, Aneesh V wrote:
> > 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.
> 
> 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.
 
> 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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Tony Lindgren]

* Rob Herring <robherring2@gmail.com> [111219 14:29]:
> On 12/19/2011 08:05 AM, Aneesh V wrote:
> > 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.
> 
> 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.
 
> 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

Re: [RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories

[Aneesh V]

Hi Olof,

On Monday 19 December 2011 10:22 PM, Olof Johansson wrote:
> 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.

>
>
> On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V<aneesh@ti.com>  wrote:
>
>> diff --git a/Documentation/devicetree/bindings/ddr/ddr.txt b/Documentation/devicetree/bindings/ddr/ddr.txt
>> new file mode 100644
>> index 0000000..f15c4dd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ddr/ddr.txt
>> @@ -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"
>
> 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).

>
>> +- io-width : string representing the io width: "x8", "x16" or "x32".
>
> No, encode as an integer.

Ok.

>
>> +
>> +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.

>
> 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.

>
> 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?

>
>> +
>> +- 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 {
>
> You will need a unit address here.

Ok. ddr-timing@0, ddr-timings@1 etc, right?

>
>> +               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 {
>
> 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.

>
>> +               min-freq        =<10000000>;
>> +               max-freq        =<200000000>;
>> +               tRP-ps          =<21000>;
>> +               tRCD-ps         =<18000>;
>> +               tWR-ps          =<15000>;
>> +               tRAS-min-ps     =<42000:;
>
> Typo

Will fix.

>
>> +               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>;
>> +       };
>> +
>> +}
>> diff --git a/Documentation/devicetree/bindings/ddr/ddr_timings.txt b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
>> new file mode 100644
>> index 0000000..38fcdec
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
>> @@ -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.

Ok. Bindings may have to be extended while adapting for other
controllers.

>
>> +
>> +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.

>
>> +
>> +- tRCD-ps
>> +- tWR-ps
>> +- tRAS-min-ps
>> +- tRRD-ps
>> +- tWTR-ps
>> +- tXP-ps
>> +- tRTP-ps
>> +- tDQSCK-max-ps
>> +- tFAW-ps
>> +- tZQCS-ps
>> +- 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.

Explained above.


Thanks for the review.

best regards,
Aneesh

[RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories

[Aneesh V]

Hi Olof,

On Monday 19 December 2011 10:22 PM, Olof Johansson wrote:
> 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.

>
>
> On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V<aneesh@ti.com>  wrote:
>
>> diff --git a/Documentation/devicetree/bindings/ddr/ddr.txt b/Documentation/devicetree/bindings/ddr/ddr.txt
>> new file mode 100644
>> index 0000000..f15c4dd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ddr/ddr.txt
>> @@ -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"
>
> 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).

>
>> +- io-width : string representing the io width: "x8", "x16" or "x32".
>
> No, encode as an integer.

Ok.

>
>> +
>> +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.

>
> 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.

>
> 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?

>
>> +
>> +- 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 {
>
> You will need a unit address here.

Ok. ddr-timing at 0, ddr-timings at 1 etc, right?

>
>> +               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 {
>
> 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.

>
>> +               min-freq        =<10000000>;
>> +               max-freq        =<200000000>;
>> +               tRP-ps          =<21000>;
>> +               tRCD-ps         =<18000>;
>> +               tWR-ps          =<15000>;
>> +               tRAS-min-ps     =<42000:;
>
> Typo

Will fix.

>
>> +               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>;
>> +       };
>> +
>> +}
>> diff --git a/Documentation/devicetree/bindings/ddr/ddr_timings.txt b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
>> new file mode 100644
>> index 0000000..38fcdec
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ddr/ddr_timings.txt
>> @@ -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.

Ok. Bindings may have to be extended while adapting for other
controllers.

>
>> +
>> +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.

>
>> +
>> +- tRCD-ps
>> +- tWR-ps
>> +- tRAS-min-ps
>> +- tRRD-ps
>> +- tWTR-ps
>> +- tXP-ps
>> +- tRTP-ps
>> +- tDQSCK-max-ps
>> +- tFAW-ps
>> +- tZQCS-ps
>> +- 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.

Explained above.


Thanks for the review.

best regards,
Aneesh

Re: [RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[Aneesh V]

On Monday 19 December 2011 10:26 PM, Olof Johansson wrote:
> Hi,
>
> Fewer comments here. :) But see below.
>
> On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V<aneesh@ti.com>  wrote:
>
>
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
>> @@ -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.
>
> 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 v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[Aneesh V]

On Monday 19 December 2011 10:26 PM, Olof Johansson wrote:
> Hi,
>
> Fewer comments here. :) But see below.
>
> On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V<aneesh@ti.com>  wrote:
>
>
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
>> @@ -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.
>
> 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

Re: [RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[Aneesh V]

On Monday 19 December 2011 10:29 PM, Olof Johansson wrote:
> Oh wait, when I saw 3/3 I realized the following too:
>
> On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V<aneesh@ti.com>  wrote:
>
>> +- 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
>
> 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.

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?

>
> 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

[RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[Aneesh V]

On Monday 19 December 2011 10:29 PM, Olof Johansson wrote:
> Oh wait, when I saw 3/3 I realized the following too:
>
> On Mon, Dec 19, 2011 at 6:05 AM, Aneesh V<aneesh@ti.com>  wrote:
>
>> +- 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
>
> 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.

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?

>
> 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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

On Tuesday 20 December 2011 04:31 AM, Rob Herring wrote:
> On 12/19/2011 08:05 AM, Aneesh V wrote:
>> 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.
>
> 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?

>
> 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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

On Tuesday 20 December 2011 04:31 AM, Rob Herring wrote:
> On 12/19/2011 08:05 AM, Aneesh V wrote:
>> 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.
>
> 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?

>
> 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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

On Tuesday 20 December 2011 05:05 AM, Tony Lindgren wrote:
> * Rob Herring<robherring2@gmail.com>  [111219 14:29]:
>> On 12/19/2011 08:05 AM, Aneesh V wrote:
>>> 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.
>>
>> 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.

>
>> 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.

> 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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

On Tuesday 20 December 2011 05:05 AM, Tony Lindgren wrote:
> * Rob Herring<robherring2@gmail.com>  [111219 14:29]:
>> On 12/19/2011 08:05 AM, Aneesh V wrote:
>>> 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.
>>
>> 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.

>
>> 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.

> 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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Cousson, Benoit]

Hi Aneesh,

On 12/20/2011 11:44 AM, Aneesh V wrote:
> On Tuesday 20 December 2011 05:05 AM, Tony Lindgren wrote:
>> * Rob Herring<robherring2@gmail.com> [111219 14:29]:
>>> On 12/19/2011 08:05 AM, Aneesh V wrote:
>>>> 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.
>>>
>>> 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.
>
>>
>>> 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.

>> 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?

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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Cousson, Benoit]

Hi Aneesh,

On 12/20/2011 11:44 AM, Aneesh V wrote:
> On Tuesday 20 December 2011 05:05 AM, Tony Lindgren wrote:
>> * Rob Herring<robherring2@gmail.com> [111219 14:29]:
>>> On 12/19/2011 08:05 AM, Aneesh V wrote:
>>>> 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.
>>>
>>> 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.
>
>>
>>> 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.

>> 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?

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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

Hi Benoit

On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
> Hi Aneesh,
>

<snip>

>>>> 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.
>
>>> 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?
>
> 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:-)

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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

Hi Benoit

On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
> Hi Aneesh,
>

<snip>

>>>> 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.
>
>>> 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?
>
> 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:-)

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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

Hi,

On Tuesday 20 December 2011 03:08 PM, Aneesh V wrote:
> Hi Benoit
>
> On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
>> Hi Aneesh,
>>
>
> <snip>
>
>>>>> 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.
>>
>>>> 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?
>>
>> 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:-)
>
> 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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

Hi,

On Tuesday 20 December 2011 03:08 PM, Aneesh V wrote:
> Hi Benoit
>
> On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
>> Hi Aneesh,
>>
>
> <snip>
>
>>>>> 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.
>>
>>>> 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?
>>
>> 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:-)
>
> 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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Olof Johansson]

Hi,

On Sun, Jan 8, 2012 at 9:23 AM, Aneesh V <aneesh@ti.com> wrote:
> Hi,
>
>
> On Tuesday 20 December 2011 03:08 PM, Aneesh V wrote:
>>
>> Hi Benoit
>>
>> On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
>>>
>>> Hi Aneesh,
>>>
>>
>> <snip>
>>
>>>>>> 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.

>>>
>>>>> 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?
>>>
>>>
>>> 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:-)
>>
>>
>> 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?

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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Olof Johansson]

Hi,

On Sun, Jan 8, 2012 at 9:23 AM, Aneesh V <aneesh@ti.com> wrote:
> Hi,
>
>
> On Tuesday 20 December 2011 03:08 PM, Aneesh V wrote:
>>
>> Hi Benoit
>>
>> On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
>>>
>>> Hi Aneesh,
>>>
>>
>> <snip>
>>
>>>>>> 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.

>>>
>>>>> 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?
>>>
>>>
>>> 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:-)
>>
>>
>> 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?

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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

Hi Olof,

On Monday 09 January 2012 11:12 AM, Olof Johansson wrote:
> Hi,
>
> On Sun, Jan 8, 2012 at 9:23 AM, Aneesh V<aneesh@ti.com>  wrote:
>> Hi,
>>
>>
>> On Tuesday 20 December 2011 03:08 PM, Aneesh V wrote:
>>>
>>> Hi Benoit
>>>
>>> On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
>>>>
>>>> Hi Aneesh,
>>>>
>>>
>>> <snip>
>>>
>>>>>>> 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.

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.

>
>>>>
>>>>>> 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?
>>>>
>>>>
>>>> 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:-)
>>>
>>>
>>> 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?
>
> 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).

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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

Hi Olof,

On Monday 09 January 2012 11:12 AM, Olof Johansson wrote:
> Hi,
>
> On Sun, Jan 8, 2012 at 9:23 AM, Aneesh V<aneesh@ti.com>  wrote:
>> Hi,
>>
>>
>> On Tuesday 20 December 2011 03:08 PM, Aneesh V wrote:
>>>
>>> Hi Benoit
>>>
>>> On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
>>>>
>>>> Hi Aneesh,
>>>>
>>>
>>> <snip>
>>>
>>>>>>> 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.

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.

>
>>>>
>>>>>> 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?
>>>>
>>>>
>>>> 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:-)
>>>
>>>
>>> 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?
>
> 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).

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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Turquette, Mike]

On Fri, Jan 13, 2012 at 11:36 AM, Aneesh V <aneesh@ti.com> wrote:
> Hi Olof,
>
>
> On Monday 09 January 2012 11:12 AM, Olof Johansson wrote:
>>
>> Hi,
>>
>> On Sun, Jan 8, 2012 at 9:23 AM, Aneesh V<aneesh@ti.com>  wrote:
>>>
>>> Hi,
>>>
>>>
>>> On Tuesday 20 December 2011 03:08 PM, Aneesh V wrote:
>>>>
>>>>
>>>> Hi Benoit
>>>>
>>>> On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
>>>>>
>>>>>
>>>>> Hi Aneesh,
>>>>>
>>>>
>>>> <snip>
>>>>
>>>>>>>> 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.
>
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Turquette, Mike]

On Fri, Jan 13, 2012 at 11:36 AM, Aneesh V <aneesh@ti.com> wrote:
> Hi Olof,
>
>
> On Monday 09 January 2012 11:12 AM, Olof Johansson wrote:
>>
>> Hi,
>>
>> On Sun, Jan 8, 2012 at 9:23 AM, Aneesh V<aneesh@ti.com> ?wrote:
>>>
>>> Hi,
>>>
>>>
>>> On Tuesday 20 December 2011 03:08 PM, Aneesh V wrote:
>>>>
>>>>
>>>> Hi Benoit
>>>>
>>>> On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
>>>>>
>>>>>
>>>>> Hi Aneesh,
>>>>>
>>>>
>>>> <snip>
>>>>
>>>>>>>> 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.
>
>
> 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

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

Hi Olof,

On Saturday 14 January 2012 01:06 AM, Aneesh V wrote:
> Hi Olof,

<snip>

> 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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

Hi Olof,

On Saturday 14 January 2012 01:06 AM, Aneesh V wrote:
> Hi Olof,

<snip>

> 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

Re: [RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories

[Aneesh V]

Hi Olof,

On Tuesday 20 December 2011 12:39 PM, Aneesh V wrote:
> Hi Olof,
>
> On Monday 19 December 2011 10:22 PM, Olof Johansson wrote:
>> 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.

>
> 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

[RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories

[Aneesh V]

Hi Olof,

On Tuesday 20 December 2011 12:39 PM, Aneesh V wrote:
> Hi Olof,
>
> On Monday 19 December 2011 10:22 PM, Olof Johansson wrote:
>> 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.

>
> 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

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[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.

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 v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[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.

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

[PATCH 1/3] dt: device tree bindings for DDR memories

[Aneesh V]

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.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>

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

diff --git a/Documentation/devicetree/bindings/ddr/lpddr2-timings.txt b/Documentation/devicetree/bindings/ddr/lpddr2-timings.txt
new file mode 100644
index 0000000..d4c1bff
--- /dev/null
+++ b/Documentation/devicetree/bindings/ddr/lpddr2-timings.txt
@@ -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@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>;
+};
diff --git a/Documentation/devicetree/bindings/ddr/lpddr2.txt b/Documentation/devicetree/bindings/ddr/lpddr2.txt
new file mode 100644
index 0000000..c03c62d
--- /dev/null
+++ b/Documentation/devicetree/bindings/ddr/lpddr2.txt
@@ -0,0 +1,106 @@
+* LPDDR2 SDRAM memories compliant to JEDEC JESD209-2
+
+Required properties:
+- compatible : Should be one of - "jedec,lpddr2-nvm", "jedec,lpddr2-s2",
+  "jedec,lpddr2-s4"
+
+  "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  : <u32> representing density in Mb (Mega bits)
+
+- io-width : <u32> representing bus width. Possible values are 8, 16, and 32
+
+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 'tck' indicates that the unit for these parameters is number
+of DDR clock cycles.
+
+- tRRD-min-tck
+- tWTR-min-tck
+- tXP-min-tck
+- tRTP-min-tck
+- tCKE-min-tck
+- tRPab-min-tck
+- tRCD-min-tck
+- tWR-min-tck
+- tRASmin-min-tck
+- tCKESR-min-tck
+- tFAW-min-tck
+
+Child nodes:
+- The lpddr2 node may have one or more child nodes of type "lpddr2-timings".
+  "lpddr2-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/lpddr2/lpddr2-timings.txt for more information on "lpddr2-timings"
+
+Example:
+
+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@0 {
+		compatible 	= "jedec,lpddr2-timings";
+		min-freq	= <10000000>;
+		max-freq	= <400000000>;
+		tRP		= <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>;
+		tZQoper		= <360000>;
+		tZQinit		= <1000000>;
+		tRAS-max-ns	= <70000>;
+	};
+
+	timings_elpida_ECB240ABACN_200mhz: lpddr2-timings@1 {
+		compatible 	= "jedec,lpddr2-timings";
+		min-freq	= <10000000>;
+		max-freq	= <200000000>;
+		tRP		= <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>;
+		tZQoper		= <360000>;
+		tZQinit		= <1000000>;
+		tRAS-max-ns	= <70000>;
+	};
+
+}
-- 
1.7.1

[PATCH 1/3] dt: device tree bindings for DDR memories

[Aneesh V]

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.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>

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

diff --git a/Documentation/devicetree/bindings/ddr/lpddr2-timings.txt b/Documentation/devicetree/bindings/ddr/lpddr2-timings.txt
new file mode 100644
index 0000000..d4c1bff
--- /dev/null
+++ b/Documentation/devicetree/bindings/ddr/lpddr2-timings.txt
@@ -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>;
+};
diff --git a/Documentation/devicetree/bindings/ddr/lpddr2.txt b/Documentation/devicetree/bindings/ddr/lpddr2.txt
new file mode 100644
index 0000000..c03c62d
--- /dev/null
+++ b/Documentation/devicetree/bindings/ddr/lpddr2.txt
@@ -0,0 +1,106 @@
+* LPDDR2 SDRAM memories compliant to JEDEC JESD209-2
+
+Required properties:
+- compatible : Should be one of - "jedec,lpddr2-nvm", "jedec,lpddr2-s2",
+  "jedec,lpddr2-s4"
+
+  "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  : <u32> representing density in Mb (Mega bits)
+
+- io-width : <u32> representing bus width. Possible values are 8, 16, and 32
+
+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 'tck' indicates that the unit for these parameters is number
+of DDR clock cycles.
+
+- tRRD-min-tck
+- tWTR-min-tck
+- tXP-min-tck
+- tRTP-min-tck
+- tCKE-min-tck
+- tRPab-min-tck
+- tRCD-min-tck
+- tWR-min-tck
+- tRASmin-min-tck
+- tCKESR-min-tck
+- tFAW-min-tck
+
+Child nodes:
+- The lpddr2 node may have one or more child nodes of type "lpddr2-timings".
+  "lpddr2-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/lpddr2/lpddr2-timings.txt for more information on "lpddr2-timings"
+
+Example:
+
+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>;
+		tRP		= <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>;
+		tZQoper		= <360000>;
+		tZQinit		= <1000000>;
+		tRAS-max-ns	= <70000>;
+	};
+
+	timings_elpida_ECB240ABACN_200mhz: lpddr2-timings at 1 {
+		compatible 	= "jedec,lpddr2-timings";
+		min-freq	= <10000000>;
+		max-freq	= <200000000>;
+		tRP		= <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>;
+		tZQoper		= <360000>;
+		tZQinit		= <1000000>;
+		tRAS-max-ns	= <70000>;
+	};
+
+}
-- 
1.7.1

[PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[Aneesh V]

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.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
 .../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

diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
new file mode 100644
index 0000000..0b166e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -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@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;
+};
-- 
1.7.1

[PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller

[Aneesh V]

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.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
 .../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

diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
new file mode 100644
index 0000000..0b166e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -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;
+};
-- 
1.7.1

[PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards

[Aneesh V]

Device tree data for the EMIF sdram controllers in OMAP4
and DDR memories attached to OMAP4 boards.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
 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

diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
new file mode 100644
index 0000000..437eaff
--- /dev/null
+++ b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
@@ -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@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@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>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index c702657..b4f3904 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -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@0x4c000000 {
+			cs1-used;
+			lpddr2-handle = <&elpida_ECB240ABACN>;
+		};
+
+		emif2: emif@0x4d000000 {
+			cs1-used;
+			lpddr2-handle = <&elpida_ECB240ABACN>;
+		};
+	};
 };
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..7959a02 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -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@0x4c000000 {
+			cs1-used;
+			lpddr2-handle = <&elpida_ECB240ABACN>;
+		};
+
+		emif2: emif@0x4d000000 {
+			cs1-used;
+			lpddr2-handle = <&elpida_ECB240ABACN>;
+		};
+	};
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index e8fe75f..6399a11 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -127,5 +127,24 @@
 			ti,hwmods = "uart4";
 			clock-frequency = <48000000>;
 		};
+
+		emif1: emif@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@0x4d000000 {
+			compatible	= "ti,emif-lpddr2";
+			ti,hwmods	= "emif2";
+			phy-type	= <1>;
+			hw-caps-read-idle-ctrl;
+			hw-caps-ll-interface;
+			hw-caps-temp-alert;
+		};
+
 	};
 };
-- 
1.7.1

[PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards

[Aneesh V]

Device tree data for the EMIF sdram controllers in OMAP4
and DDR memories attached to OMAP4 boards.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
 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

diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
new file mode 100644
index 0000000..437eaff
--- /dev/null
+++ b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
@@ -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>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index c702657..b4f3904 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -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>;
+		};
+	};
 };
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..7959a02 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -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>;
+		};
+	};
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index e8fe75f..6399a11 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -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;
+		};
+
 	};
 };
-- 
1.7.1

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

On Thursday 19 January 2012 07:58 PM, Aneesh V wrote:
> 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.

Please ignore this series. I did git-send-email from wrong directory.

>
> 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 v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

On Thursday 19 January 2012 07:58 PM, Aneesh V wrote:
> 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.

Please ignore this series. I did git-send-email from wrong directory.

>
> 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
>

Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Olof Johansson]

Hi,

On Mon, Jan 16, 2012 at 11:15 AM, Turquette, Mike <mturquette@ti.com> wrote:

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Olof Johansson]

Hi,

On Mon, Jan 16, 2012 at 11:15 AM, Turquette, Mike <mturquette@ti.com> wrote:

> 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