* [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories
2012-01-19 14:31 [RFC v3 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR Aneesh V
@ 2012-01-19 14:31 ` Aneesh V
2012-01-19 19:31 ` Olof Johansson
2012-01-19 14:32 ` [RFC v3 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller Aneesh V
2012-01-19 14:32 ` [RFC v3 PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards Aneesh V
2 siblings, 1 reply; 8+ messages in thread
From: Aneesh V @ 2012-01-19 14:31 UTC (permalink / raw)
To: linux-arm-kernel
device tree bindings for LPDDR2 SDRAM memories compliant
to JESD209-2 standard.
The 'lpddr2' binding in-turn uses another binding 'lpddr2-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>
Cc: Olof Johansson <olof@lixom.net>
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
Changes in RFC v3:
* Removed DDR3 support
* Fixed review comments on RFC v2
---
.../devicetree/bindings/lpddr2/lpddr2-timings.txt | 51 ++++++++++
.../devicetree/bindings/lpddr2/lpddr2.txt | 102 ++++++++++++++++++++
2 files changed, 153 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2.txt
diff --git a/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt b/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
new file mode 100644
index 0000000..1483841
--- /dev/null
+++ b/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
@@ -0,0 +1,51 @@
+* 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. Type is <u32>
+- max-freq : maximum DDR clock frequency for the speed-bin. Type is <u32>
+
+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). Parameters with
+a different unit have a suffix indicating the unit such as 'tRAS-max-ns'
+- 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/lpddr2/lpddr2.txt b/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
new file mode 100644
index 0000000..9c175f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
@@ -0,0 +1,102 @@
+* 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.
+- 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
^ permalink raw reply related [flat|nested] 8+ messages in thread* [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories
2012-01-19 14:31 ` [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories Aneesh V
@ 2012-01-19 19:31 ` Olof Johansson
2012-01-19 20:56 ` Aneesh V
0 siblings, 1 reply; 8+ messages in thread
From: Olof Johansson @ 2012-01-19 19:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Sorry for the delay in responding, I know you pinged me about it yesterday.
On Thu, Jan 19, 2012 at 6:31 AM, Aneesh V <aneesh@ti.com> wrote:
> device tree bindings for LPDDR2 SDRAM memories compliant
> to JESD209-2 standard.
>
> The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
> for specifying the AC timing parameters of the memory device at
> different speed-bins.
As I just commented on the thread with Mike, I think we would be
better off sticking to embedding a standard JEDEC SPD structure in the
device tree. It's not large (128-256 bytes depending on memory type),
and it's clearly defined and used all over the industry.
It also has the benefit of reusing parsing code if you ever end up
with a system that uses DIMMs for memory, thus needing to parse the
SPD on said modules.
-Olof
^ permalink raw reply [flat|nested] 8+ messages in thread
* [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories
2012-01-19 19:31 ` Olof Johansson
@ 2012-01-19 20:56 ` Aneesh V
2012-01-21 7:28 ` Olof Johansson
0 siblings, 1 reply; 8+ messages in thread
From: Aneesh V @ 2012-01-19 20:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof,
On Friday 20 January 2012 01:01 AM, Olof Johansson wrote:
> Hi,
>
> Sorry for the delay in responding, I know you pinged me about it yesterday.
>
> On Thu, Jan 19, 2012 at 6:31 AM, Aneesh V<aneesh@ti.com> wrote:
>> device tree bindings for LPDDR2 SDRAM memories compliant
>> to JESD209-2 standard.
>>
>> The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
>> for specifying the AC timing parameters of the memory device at
>> different speed-bins.
>
> As I just commented on the thread with Mike, I think we would be
> better off sticking to embedding a standard JEDEC SPD structure in the
> device tree. It's not large (128-256 bytes depending on memory type),
> and it's clearly defined and used all over the industry.
>
> It also has the benefit of reusing parsing code if you ever end up
> with a system that uses DIMMs for memory, thus needing to parse the
> SPD on said modules.
I did mention in the previous thread why SPD doesn't work for us ([1]
and [2]). Let me repeat the key points here.
1. I couldn't find an SPD addendum for LPDDR2 from the JEDEC website.
2. This seems to indicate that SPD is not used for LPDDR2 devices.
3. I tried to see if I can fit the DDR3 or DDR2 SPD for our needs. But
some of the AC timing parameters needed by our controller are not
available in those layouts.
I don't see any option other than defining a new binding for LPDDR2.
br,
Aneesh
[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg61250.html
[2] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg60473.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories
2012-01-19 20:56 ` Aneesh V
@ 2012-01-21 7:28 ` Olof Johansson
2012-01-21 8:09 ` Aneesh V
0 siblings, 1 reply; 8+ messages in thread
From: Olof Johansson @ 2012-01-21 7:28 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 19, 2012 at 12:56 PM, Aneesh V <aneesh@ti.com> wrote:
> Hi Olof,
>
>
> On Friday 20 January 2012 01:01 AM, Olof Johansson wrote:
>>
>> Hi,
>>
>> Sorry for the delay in responding, I know you pinged me about it
>> yesterday.
>>
>> On Thu, Jan 19, 2012 at 6:31 AM, Aneesh V<aneesh@ti.com> ?wrote:
>>>
>>> device tree bindings for LPDDR2 SDRAM memories compliant
>>> to JESD209-2 standard.
>>>
>>> The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
>>> for specifying the AC timing parameters of the memory device at
>>> different speed-bins.
>>
>>
>> As I just commented on the thread with Mike, I think we would be
>> better off sticking to embedding a standard JEDEC SPD structure in the
>> device tree. It's not large (128-256 bytes depending on memory type),
>> and it's clearly defined and used all over the industry.
>>
>> It also has the benefit of reusing parsing code if you ever end up
>> with a system that uses DIMMs for memory, thus needing to parse the
>> SPD on said modules.
>
>
> I did mention in the previous thread why SPD doesn't work for us ([1] and
> [2]). Let me repeat the key points here.
Ah, sorry. Missed it in the chain of replies.
> 1. I couldn't find an SPD addendum for LPDDR2 from the JEDEC website.
> 2. This seems to indicate that SPD is not used for LPDDR2 devices.
Bummer. I'm guessing most applications where LPDDR* is used won't be
suitable for modular memory, so there's not the same need for SPD.
> 3. I tried to see if I can fit the DDR3 or DDR2 SPD for our needs. But
> some of the AC timing parameters needed by our controller are not
> available in those layouts.
Are those properties of the memory, or a combination of memory and
board properties? I think it still makes sense for the memories that
do have it to use the SPD format and extend with additional
properties, at least if it's only a few additional properties needed.
> I don't see any option other than defining a new binding for LPDDR2.
Yeah, agreed.
-Olof
^ permalink raw reply [flat|nested] 8+ messages in thread
* [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories
2012-01-21 7:28 ` Olof Johansson
@ 2012-01-21 8:09 ` Aneesh V
0 siblings, 0 replies; 8+ messages in thread
From: Aneesh V @ 2012-01-21 8:09 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 21 January 2012 12:58 PM, Olof Johansson wrote:
> On Thu, Jan 19, 2012 at 12:56 PM, Aneesh V<aneesh@ti.com> wrote:
>> Hi Olof,
>>
>>
>> On Friday 20 January 2012 01:01 AM, Olof Johansson wrote:
>>>
>>> Hi,
>>>
>>> Sorry for the delay in responding, I know you pinged me about it
>>> yesterday.
>>>
>>> On Thu, Jan 19, 2012 at 6:31 AM, Aneesh V<aneesh@ti.com> wrote:
>>>>
>>>> device tree bindings for LPDDR2 SDRAM memories compliant
>>>> to JESD209-2 standard.
>>>>
>>>> The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
>>>> for specifying the AC timing parameters of the memory device at
>>>> different speed-bins.
>>>
>>>
>>> As I just commented on the thread with Mike, I think we would be
>>> better off sticking to embedding a standard JEDEC SPD structure in the
>>> device tree. It's not large (128-256 bytes depending on memory type),
>>> and it's clearly defined and used all over the industry.
>>>
>>> It also has the benefit of reusing parsing code if you ever end up
>>> with a system that uses DIMMs for memory, thus needing to parse the
>>> SPD on said modules.
>>
>>
>> I did mention in the previous thread why SPD doesn't work for us ([1] and
>> [2]). Let me repeat the key points here.
>
> Ah, sorry. Missed it in the chain of replies.
>
>> 1. I couldn't find an SPD addendum for LPDDR2 from the JEDEC website.
>> 2. This seems to indicate that SPD is not used for LPDDR2 devices.
>
> Bummer. I'm guessing most applications where LPDDR* is used won't be
> suitable for modular memory, so there's not the same need for SPD.
>
>> 3. I tried to see if I can fit the DDR3 or DDR2 SPD for our needs. But
>> some of the AC timing parameters needed by our controller are not
>> available in those layouts.
>
> Are those properties of the memory, or a combination of memory and
> board properties? I think it still makes sense for the memories that
> do have it to use the SPD format and extend with additional
> properties, at least if it's only a few additional properties needed.
They are AC timing parameters defined by the spec such as tCKESR, tFAW
etc, nothing specific to OMAP.
As for other memories, we do not intend to support any at the moment.
In my initial version I had bindings for DDR3, because we intended to
have DDR3 support in the driver. But we have since decided to drop DDR3
support for the following reasons:
1. According to the DDR3 spec, the operating frequency range for the
speed-bins is limited (unlike LPDDR2). Scaling DDR frequency in this
small range doesn't make sense for us (this may be the case for other
platforms too).
2. Unlike LPDDR2, DDR3 doesn't have a mechanism for polling the
temperature from the device and derate timings.
If DVFS and thermal handling are not relevant for DDR3, having a kernel
driver doesn't make sense. One-time settings in the bootloader are good
enough.
So, I have made my binding only for LPDDR2 and removed DDR3 parts from
it.
>
>> I don't see any option other than defining a new binding for LPDDR2.
>
> Yeah, agreed.
Thanks,
Aneesh
^ permalink raw reply [flat|nested] 8+ messages in thread
* [RFC v3 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller
2012-01-19 14:31 [RFC v3 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR Aneesh V
2012-01-19 14:31 ` [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories Aneesh V
@ 2012-01-19 14:32 ` Aneesh V
2012-01-19 14:32 ` [RFC v3 PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards Aneesh V
2 siblings, 0 replies; 8+ messages in thread
From: Aneesh V @ 2012-01-19 14:32 UTC (permalink / raw)
To: linux-arm-kernel
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>
Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
Changes in RFC v3:
* Fixed review comments from RFC v2
---
.../bindings/memory-controllers/ti/emif.txt | 49 ++++++++++++++++++++
1 files changed, 49 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..2925add
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -0,0 +1,49 @@
+* 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 : Should be of the form "ti,emif-<ip-rev>" where <ip-rev>
+ is the IP revision of the specific EMIF instance.
+
+- phy-type : <u32> indicating the DDR phy type. Following are the
+ allowed values
+ <1> : Attila PHY
+ <2> : Intelli PHY
+
+- device-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-4d";
+ ti,hwmods = "emif2";
+ phy-type = <1>;
+ device-handle = <&elpida_ECB240ABACN>;
+ cs1-used;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+};
--
1.7.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* [RFC v3 PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards
2012-01-19 14:31 [RFC v3 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR Aneesh V
2012-01-19 14:31 ` [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories Aneesh V
2012-01-19 14:32 ` [RFC v3 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller Aneesh V
@ 2012-01-19 14:32 ` Aneesh V
2 siblings, 0 replies; 8+ messages in thread
From: Aneesh V @ 2012-01-19 14:32 UTC (permalink / raw)
To: linux-arm-kernel
Device tree data for the EMIF sdram controllers in OMAP4
and LPDDR memory devices attached to OMAP4 boards.
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Aneesh V <aneesh@ti.com>
---
Changes in RFC v3:
* Fixed review comments from RFC v2
---
arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 65 +++++++++++++++++++++++++++++
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, 110 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..2384233
--- /dev/null
+++ b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
@@ -0,0 +1,65 @@
+/*
+ * 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 {
+ compatible = "jedec,lpddr2-timings";
+ 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..9b46802 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;
+ device-handle = <&elpida_ECB240ABACN>;
+ };
+
+ emif2: emif at 0x4d000000 {
+ cs1-used;
+ device-handle = <&elpida_ECB240ABACN>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..896d682 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;
+ device-handle = <&elpida_ECB240ABACN>;
+ };
+
+ emif2: emif at 0x4d000000 {
+ cs1-used;
+ device-handle = <&elpida_ECB240ABACN>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index e8fe75f..bd57229 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-4d";
+ ti,hwmods = "emif1";
+ phy-type = <1>;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
+
+ emif2: emif at 0x4d000000 {
+ compatible = "ti,emif-4d";
+ ti,hwmods = "emif2";
+ phy-type = <1>;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
+
};
};
--
1.7.1
^ permalink raw reply related [flat|nested] 8+ messages in thread