Hi, On Mon, Jan 16, 2012 at 11:15 AM, Turquette, Mike <mturquette@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
