Re: Device tree binding for DVFS table

Hi Mike,

Peter,

I agree with your observations in general, but I think some specificity
is needed:

quoted

+ 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?

quoted

+ 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.

quoted

+ 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.