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

[Olof Johansson]

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