[RFC v2 PATCH 1/3] dt: device tree bindings for DDR memories
aneesh at ti.com
Thu Jan 19 07:18:52 EST 2012
On Tuesday 20 December 2011 12:39 PM, Aneesh V wrote:
> Hi Olof,
> On Monday 19 December 2011 10:22 PM, Olof Johansson wrote:
>> 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.
More information about the linux-arm-kernel