On 10/17/18 3:37 PM, Dmitry Osipenko wrote: > On 10/17/18 11:40 AM, Jon Hunter wrote: >> >> On 30/08/2018 20:43, 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 >> >> Is it likely that 'backup' will be anything other that pll_p? If not why >> not just call it pll_p? Personally, I don't 'backup' to descriptive even >> though I can see what you mean. >> >> I can see that you want to make this flexible, but if the likelihood is >> that we will just use pll_p then I am not sure it is warranted at this >> point. > > That won't describe HW, but software. And device tree should describe HW. > Though indeed it is unlikely that anything else other than pll_p will be used, so it is a software/firmware description anyway.
