From: Aneesh V <aneesh@ti.com> To: Rob Herring <robherring2@gmail.com> Cc: devicetree-discuss@lists.ozlabs.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR Date: Tue, 20 Dec 2011 15:46:49 +0530 [thread overview] Message-ID: <4EF06091.1050102@ti.com> (raw) In-Reply-To: <4EEFC23A.30201@gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: aneesh@ti.com (Aneesh V) To: linux-arm-kernel@lists.infradead.org Subject: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR Date: Tue, 20 Dec 2011 15:46:49 +0530 [thread overview] Message-ID: <4EF06091.1050102@ti.com> (raw) In-Reply-To: <4EEFC23A.30201@gmail.com> 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
next prev parent reply other threads:[~2011-12-20 10:16 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-12-19 14:05 [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR Aneesh V 2011-12-19 14:05 ` Aneesh V 2011-12-19 14:05 ` [RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories Aneesh V 2011-12-19 14:05 ` Aneesh V 2011-12-19 16:52 ` Olof Johansson 2011-12-19 16:52 ` Olof Johansson 2011-12-20 7:09 ` Aneesh V 2011-12-20 7:09 ` Aneesh V 2012-01-19 12:18 ` Aneesh V 2012-01-19 12:18 ` Aneesh V 2011-12-19 14:05 ` [RFC v2 PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller Aneesh V 2011-12-19 14:05 ` Aneesh V 2011-12-19 16:56 ` Olof Johansson 2011-12-19 16:56 ` Olof Johansson 2011-12-20 7:12 ` Aneesh V 2011-12-20 7:12 ` Aneesh V 2011-12-19 16:59 ` Olof Johansson 2011-12-19 16:59 ` Olof Johansson 2011-12-20 7:19 ` Aneesh V 2011-12-20 7:19 ` Aneesh V 2011-12-19 14:05 ` [RFC v2 PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards Aneesh V 2011-12-19 14:05 ` Aneesh V 2011-12-19 23:01 ` [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR Rob Herring 2011-12-19 23:01 ` Rob Herring 2011-12-19 23:35 ` Tony Lindgren 2011-12-19 23:35 ` Tony Lindgren 2011-12-20 10:44 ` Aneesh V 2011-12-20 10:44 ` Aneesh V 2011-12-20 12:40 ` Cousson, Benoit 2011-12-20 12:40 ` Cousson, Benoit 2011-12-20 14:08 ` Aneesh V 2011-12-20 14:08 ` Aneesh V 2012-01-08 17:23 ` Aneesh V 2012-01-08 17:23 ` Aneesh V 2012-01-09 5:42 ` Olof Johansson 2012-01-09 5:42 ` Olof Johansson 2012-01-13 19:36 ` Aneesh V 2012-01-13 19:36 ` Aneesh V 2012-01-16 19:15 ` Turquette, Mike 2012-01-16 19:15 ` Turquette, Mike 2012-01-19 19:26 ` Olof Johansson 2012-01-19 19:26 ` Olof Johansson 2012-01-17 12:06 ` Aneesh V 2012-01-17 12:06 ` Aneesh V 2011-12-20 10:16 ` Aneesh V [this message] 2011-12-20 10:16 ` Aneesh V 2012-01-19 14:28 ` Aneesh V 2012-01-19 14:28 ` Aneesh V 2012-01-19 14:31 ` Aneesh V 2012-01-19 14:31 ` Aneesh V 2012-01-19 14:28 ` [PATCH 1/3] dt: device tree bindings for DDR memories Aneesh V 2012-01-19 14:28 ` Aneesh V 2012-01-19 14:28 ` [PATCH 2/3] dt: device tree bindings for TI's EMIF sdram controller Aneesh V 2012-01-19 14:28 ` Aneesh V 2012-01-19 14:28 ` [PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards Aneesh V 2012-01-19 14:28 ` Aneesh V
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4EF06091.1050102@ti.com \ --to=aneesh@ti.com \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=robherring2@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.