From: Aneesh V <aneesh@ti.com>
To: Olof Johansson <olof@lixom.net>
Cc: devicetree-discuss@lists.ozlabs.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Rajendra Nayak <rnayak@ti.com>, Benoit Cousson <b-cousson@ti.com>
Subject: Re: [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories
Date: Fri, 20 Jan 2012 02:26:38 +0530 [thread overview]
Message-ID: <4F188386.3080507@ti.com> (raw)
In-Reply-To: <CAOesGMikm8szKR_yyeV-4NbnknCLG3z9N_sj+zydyu+cosj-Tg@mail.gmail.com>
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@vger.kernel.org/msg61250.html
[2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60473.html
WARNING: multiple messages have this Message-ID (diff)
From: aneesh@ti.com (Aneesh V)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories
Date: Fri, 20 Jan 2012 02:26:38 +0530 [thread overview]
Message-ID: <4F188386.3080507@ti.com> (raw)
In-Reply-To: <CAOesGMikm8szKR_yyeV-4NbnknCLG3z9N_sj+zydyu+cosj-Tg@mail.gmail.com>
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
next prev parent reply other threads:[~2012-01-19 20:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
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 14:31 ` [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories Aneesh V
2012-01-19 14:31 ` Aneesh V
2012-01-19 19:31 ` Olof Johansson
2012-01-19 19:31 ` Olof Johansson
2012-01-19 20:56 ` Aneesh V [this message]
2012-01-19 20:56 ` Aneesh V
2012-01-21 7:28 ` Olof Johansson
2012-01-21 7:28 ` Olof Johansson
2012-01-21 8:09 ` Aneesh V
2012-01-21 8:09 ` 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
2012-01-19 14:32 ` [RFC v3 PATCH 3/3] arm/dts: EMIF and lpddr2 device tree data for OMAP4 boards Aneesh V
2012-01-19 14:32 ` 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=4F188386.3080507@ti.com \
--to=aneesh@ti.com \
--cc=b-cousson@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=olof@lixom.net \
--cc=rnayak@ti.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.