[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR

[Aneesh V]

Hi Benoit

On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote:
> Hi Aneesh,
>

<snip>

>>>> 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
>>
>> As far as I understand, in the current out-of-tree DVFS implementation
>> for OMAP, DVFS can start even before user-space.
>
> Maybe it is the case, but that does not mean it should.
> We can potentially delay the DVFS init until the user-space is started.
> This should not be considered as a big constraint.
>
>>> 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".
>>
>> Do you mean one module per memory device and have all timing data in
>> the respective module? Wouldn't this clutter the kernel proper with all
>> these tables. By having the timing data in DT, it can be eventually
>> moved out of kernel eventually, right?
>
> Yes, that's the theory, but referring to Olof's point, this is not
> necessarily the goal of DT to store all the information that are not
> board dependent.
> In this case, each DDR will have it sets of well known AC timings data
> that will never depend of the board config. In this case, storing that
> inside DT might not be the best solution.
>
> In fact we always had the same kind of discussion for the pinmux data
> and for the clock data...
>
> The conclusion being that most of the static data does not have to be in
> the DTS.
> But since Linus was complaining about the huge amount of data inside the
> kernel, it is not obvious what the best solution is:-)

Hmm.. I get the point now. Linus' complaint is what I had in mind too.
My humble opinion is to have such data in DTS but re-use it as much as
possible. That is, we could have something like a "sdram-micron-
mt46h32m32lf-6.dtsi"(as you suggested before) that can be included by
board level DTS files. I think the fact that dts files are organized at
arch level today is limiting such re-use. Please correct me if I am
wrong.

br,
Aneesh