On 06.11.2018 0:30, Rob Herring wrote:
> On Sun, Oct 21, 2018 at 11:54:47PM +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 <[email protected]>
>> ---
>> .../cpufreq/nvidia,tegra20-cpufreq.txt | 96 +++++++++++++++++++
>> 1 file changed, 96 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..a8023ea7a99f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
>> @@ -0,0 +1,96 @@
>> +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
>> + - intermediate: intermediate-parent for CPU clock
>> + - cclk: the CPU clock
>> +- operating-points-v2: See ../bindings/opp/opp.txt for details.
>> +- #cooling-cells: Should be 2. See ../thermal/thermal.txt for details.
>> +
>> +For each opp entry in 'operating-points-v2' table:
>> +- opp-supported-hw: Two bitfields indicating:
>> + On Tegra20:
>> + 1. CPU process ID mask
>> + 2. SoC speedo ID mask
>> +
>> + On Tegra30:
>> + 1. CPU process ID mask
>> + 2. CPU speedo ID mask
>> +
>> + A bitwise AND is performed against these values and if any bit
>> + matches, the OPP gets enabled.
>> +
>> +- opp-microvolt: CPU voltage triplet.
>> +
>> +Optional properties:
>> +- cpu-supply: Phandle to the CPU power supply.
>> +- core-supply: Phandle to the CORE power supply.
>> +- rtc-supply: Phandle to the RTC power supply, required only for Tegra20.
>> +
>> +Voltage supply requirements:
>> +- Tegra20:
>> + CORE and RTC regulators must be coupled using the regulator-coupled-with
>> + property and regulator-coupled-max-spread property must be set to no
>> + more than 170mV.
>> +
>> + See ../regulator/regulator.txt for more detail about the properties.
>> +
>> +- Tegra30:
>> + CORE and CPU regulators must be coupled using the regulator-coupled-with
>> + property and regulator-coupled-max-spread property must be set to no
>> + more than 300mV. Each of CORE and CPU regulators must set
>> + regulator-max-step-microvolt property to no more than 100mV.
>> +
>> + See ../regulator/regulator.txt for more detail about the properties.
>> +
>> +
>> +Example:
>> + regulators {
>> + cpu_reg: regulator0 {
>> + regulator-name = "vdd_cpu";
>> + };
>> +
>> + core_reg: regulator1 {
>> + regulator-name = "vdd_core";
>> + regulator-coupled-with = <&rtc_reg>;
>> + regulator-coupled-max-spread = <170000>;
>> + };
>> +
>> + rtc_reg: regulator2 {
>> + regulator-name = "vdd_rtc";
>> + regulator-coupled-with = <&core_reg>;
>> + regulator-coupled-max-spread = <170000>;
>> + };
>> + };
>> +
>> + cpu0_opp_table: opp_table0 {
>> + compatible = "operating-points-v2";
>> +
>> + opp@456000000 {
>> + clock-latency-ns = <125000>;
>> + opp-microvolt = <825000 825000 1125000>;
>> + opp-supported-hw = <0x03 0x0001>;
>> + opp-hz = /bits/ 64 <456000000>;
>> + };
>> +
>> + ...
>> + };
>> +
>> + cpus {
>> + cpu@0 {
>> + compatible = "arm,cortex-a9";
>> + clocks = <&tegra_car TEGRA20_CLK_PLL_X>,
>> + <&tegra_car TEGRA20_CLK_PLL_P>,
>> + <&tegra_car TEGRA20_CLK_CCLK>;
>> + clock-names = "pll_x", "intermediate", "cclk";
>
> I still object to having clocks (and supplies) which don't reflect the
> h/w and are documented in the CA9 TRM.
>
>> + operating-points-v2 = <&cpu0_opp_table>;
>> + cpu-supply = <&cpu_reg>;
>> + core-supply = <&core_reg>;
>> + rtc-supply = <&rtc_reg>;
>
> Supplies are suspect too, but perhaps supplies and power domains are
> beyond the scope of the TRM and part of the physical design.
Is it possible to have a "firmware" device-tree node specifically for cpufreq
driver? Something like this:
cpufreq {
compatible = "nvidia,tegra20-cpufreq";
clocks = <&tegra_car TEGRA20_CLK_PLL_X>,
<&tegra_car TEGRA20_CLK_PLL_P>;
clock-names = "pll_x", "intermediate";
};
We may also need a Tegra-specific DVFS helper-driver that will help to manage
CPU-CORE voltage dependency. Yet I'll have to examine this all in more details,
but maybe it will be nicer if DVFS could be instantiated via device-tree as
well. It will provide a Tegra-specific DVFS API and manage CORE / RTC
dependencies for the CPUFreq and peripheral drivers, also helping to maintain
proper voltages during kernel boot-up until all drivers are brought into action.
cpufreq {
compatible = "nvidia,tegra20-dvfs";
cpu-supply = <&cpu_vdd_reg>;
core-supply = <&core_vdd_reg>;
rtc-supply = <&rtc_vdd_reg>;
};
So my question is:
Is it possible to have device-tree nodes that solely describe firmware? Kernel
drivers in this case.
