[RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR
Olof Johansson
olof at lixom.net
Fri Jan 20 06:26:55 EST 2012
Hi,
On Mon, Jan 16, 2012 at 11:15 AM, Turquette, Mike <mturquette at ti.com> wrote:
> And delaying DVFS (at least for the parts affecting mem) until
> userspace is loaded doesn't seem great to me either. We're basically
> pushing back feature readiness (with respect to boot sequence) in the
> name of organizing data in a pretty way... but it's not a pretty
> solution since the data will have to be "split" as shown above.
Ok, so let's put the JEDEC SPD data in the device tree then. But I
fail to see how that changes the "split"? There's still two sources of
configuration, one from firmware used at boot and one from a data
structure that the kernel uses.
I do think sticking to an existing well-defined data structure such as
SPD data is to be preferred over doing an open-coded new binding. This
way, some platforms that might or might not have SPD in hardware can
use the same code paths (i.e. a board that has memory on a DIMM
instead of soldered down, or that uses soldered-down SPD).
-Olof
More information about the devicetree-discuss
mailing list