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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
