On 21/03/16 17:51, Mark Brown wrote: > On Mon, Mar 21, 2016 at 05:24:52PM +0000, Juri Lelli wrote: > > > I think this should work, but we have to understand how do we obtain the > > max frequency of each cluster while parsing DT. OPP bindings are > > helpful, but AFAIK there are platforms for which firmware is responsible > > for setting up and advertise available OPPs. I'm not sure if this > > happens later on during the boot process. We might still be able to use > > the clock-frequency property in this case, but that might need changing > > again if the top OPP gets removed/changed. > > > OTH, we might simply want to say that capacity values are to be obtained > > once the platform is "stable" (no additional changes to configuration, > > OPPs, etc.). But this is maybe not acceptable? > > How about we just punt and let the cpufreq driver tell us - it can parse > DT, use built in tables or whatever? We could even remember the raw > values and recalculate if it ever decides to change for some reason. > Until cpufreq comes up we'll be stuck at whatever OPP that we're at on > startup which may not match whatever we define the numbers relative to > anyway. > OK, I'll try and see how that can be done. Thanks, - Juri > > Also, I fear that for variants of a particular implementation we will > > still have to redo the profiling anyway (like we alreaady did for Juno > > and Juno-r2 for example). > > This sometimes happens either through binning or through board design > decisions rather than through new silicon so we might be able to reuse. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
