All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Rob Herring <robherring2@gmail.com>
Cc: Aneesh V <aneesh@ti.com>,
	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: Mon, 19 Dec 2011 15:35:59 -0800	[thread overview]
Message-ID: <20111219233559.GW6464@atomide.com> (raw)
In-Reply-To: <4EEFC23A.30201@gmail.com>

* 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

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR
Date: Mon, 19 Dec 2011 15:35:59 -0800	[thread overview]
Message-ID: <20111219233559.GW6464@atomide.com> (raw)
In-Reply-To: <4EEFC23A.30201@gmail.com>

* 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

  reply	other threads:[~2011-12-19 23:35 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 [this message]
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
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=20111219233559.GW6464@atomide.com \
    --to=tony@atomide.com \
    --cc=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: link
Be 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.