On 9/25/18 7:58 PM, Rob Herring wrote: > On Thu, Aug 30, 2018 at 10:43:52PM +0300, Dmitry Osipenko wrote: >> Add device-tree binding that describes CPU frequency-scaling hardware >> found on NVIDIA Tegra20/30 SoC's. >> >> Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx> >> --- >> .../cpufreq/nvidia,tegra20-cpufreq.txt | 38 +++++++++++++++++++ >> 1 file changed, 38 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt >> >> diff --git a/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt >> new file mode 100644 >> index 000000000000..2c51f676e958 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt >> @@ -0,0 +1,38 @@ >> +Binding for NVIDIA Tegra20 CPUFreq >> +================================== >> + >> +Required properties: >> +- clocks: Must contain an entry for each entry in clock-names. >> + See ../clocks/clock-bindings.txt for details. >> +- clock-names: Must include the following entries: >> + - pll_x: main-parent for CPU clock, must be the first entry >> + - backup: intermediate-parent for CPU clock >> + - cpu: the CPU clock > > The Cortex A9 has CLK, PERIPHCLK, and PERIPHCLKEN clocks and only CLK > is used for the cpu core. You can't just define your own clocks that > you happen to want access to. > > Otherwise, you're not defining anything new here, so a binding document > isn't required. PERIPHCLK is a different thing. Here we are defining the CPU clock and its *parent* sources, the PLLX (main) and backup (intermediate clock that is used while PLLX changes its rate). These are not some random clocks "that you happen to want access to", they are essential for the Tegra CPUFreq driver, CPU is running off them. I assume that PERIPHCLK and other clocks are derived from the "CPU" clock and their configuration is hardwired. Probably Peter knows how it's implemented in HW. I'm now working on v2 that will include more Tegra-specific stuff in the binding, like custom "opp-supported-hw" property and probably some more.
