Hi Mike, > > Peter, > > I agree with your observations in general, but I think some specificity > is needed: > > > + frequency/voltage relationships > > We should be clear that the voltage does NOT belong to the clock, but to > the device/module/IP block that consumes that clock. This is an > important detail since it means that a clock does not have a > corresponding table of voltages (e.g. one table per clock), but instead > a device has a table of voltages corresponding to each clock. > Or the other way around, a table of clock frequencies, 1 for each voltage. > This is very necessary when a single clock drives multiple devices which > are driven by separate voltage rails. > Ah ok. How does this work in practice? A device can only run at a given clock rate if all the rails are at a certain voltage? > > + power rail constraints (eg voltage difference limit between 2 rails) > > This should come from regulator DT data and not anything DVFS-specific, > correct? > That's true. I think it can even be open-coded as this is a SoC internal thing. All boards using this SoC will have the same limits, so I see little reason to move this info to DT. > > + clock constraints (eg. clock x frequency must be a fixed ratio of clock y > > frequency) > > Yeah, after sending my email above yesterday I instantly regretted it. > It is true that *functional* clock dependencies are really the purview > of the device driver. E.g. for Device X to operate at FAST_SPEED, scale > functional_clk up to 200MHz and l3_ddr_clk up to 100MHz. On OMAP our > display subsystem block also has clock ratio rules that must be honored, > but it just open-coded. > > It is possible to model those in DT if we really want, but shouldn't be > a priority for these dvfs-specific bindings. > Agreed. Cheers, Peter. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
