| Message ID | 1420723339-30735-2-git-send-email-mikko.perttunen@kapsi.fi (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jan 08, 2015 at 03:22:04PM +0200, Mikko Perttunen wrote: > From: Tuomas Tynkkynen <ttynkkynen@nvidia.com> > > The DFLL is the main clocksource for the fast CPU cluster on Tegra124 > and also provides automatic CPU rail voltage scaling as well. The DFLL > is a separate IP block from the usual Tegra124 clock-and-reset > controller, so it gets its own node in the device tree. > Please add devicetree@vger.kernel.org to the next CC list. Peter.
On Thu, Jan 08, 2015 at 03:22:04PM +0200, Mikko Perttunen wrote: > From: Tuomas Tynkkynen <ttynkkynen@nvidia.com> > > The DFLL is the main clocksource for the fast CPU cluster on Tegra124 > and also provides automatic CPU rail voltage scaling as well. The DFLL > is a separate IP block from the usual Tegra124 clock-and-reset > controller, so it gets its own node in the device tree. > > Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> > Signed-off-by: Mikko Perttunen <mikko.perttunen@kapsi.fi> > --- > .../bindings/clock/nvidia,tegra124-dfll.txt | 69 ++++++++++++++++++++++ > 1 file changed, 69 insertions(+) > create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt > > diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt > new file mode 100644 > index 0000000..54c62ac > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt > @@ -0,0 +1,69 @@ > +NVIDIA Tegra124 DFLL FCPU clocksource > + > +This binding uses the common clock binding: > +Documentation/devicetree/bindings/clock/clock-bindings.txt > + > +The DFLL IP block on Tegra is a root clocksource designed for clocking > +the fast CPU cluster. It consists of a free-running voltage controlled > +oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop > +control module that will automatically adjust the VDD_CPU voltage by > +communicating with an off-chip PMIC either via an I2C bus or via PWM signals. How would PWM communication work? The documentation below doesn't describe it, so perhaps either leave that part out until the binding is updated to support it, or maybe make an explicit note that this mode of operation isn't supported yet? > +Required properties: > +- compatible : should be "nvidia,tegra124-dfll-fcpu" > +- reg : Defines the following set of registers, in the order listed: > + - registers for the DFLL control logic. > + - registers for the I2C output logic. > + - registers for the integrated I2C master controller. > + - look-up table RAM for voltage register values. Why do these all need to be separate sets? According to the TRM this is a single IP block with a single register region, why the need to split them apart? > +- interrupts: Should contain the DFLL block interrupt. > +- 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: > + - soc: Clock source for the DFLL control logic. > + - ref: The closed loop reference clock > + - i2c: Clock source for the integrated I2C master. > +- #clock-cells: Must be 0. > +- clock-output-names: Name of the clock output. > +- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL > + hardware will start controlling. How does the hardware control it? How do we go from regulator phandle to something that the hardware will know how to access? > +Required properties for the control loop parameters: > +- nvidia,sample-rate: Sample rate of the DFLL control loop. > +- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM. > +- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM. > +- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM. > +- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM. > +- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM. > +- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM. > + > +Required properties for I2C mode: > +- nvidia,i2c-fs-rate: I2C transfer rate, if using FS mode. What's FS mode? > + > +Example: > + > +dfll@0,70110000 { Perhaps this should be "clock@0,70110000"? > + compatible = "nvidia,tegra124-dfll"; > + reg = <0 0x70110000 0 0x100>, /* DFLL control */ > + <0 0x70110000 0 0x100>, /* I2C output control */ > + <0 0x70110100 0 0x100>, /* Integrated I2C controller */ > + <0 0x70110200 0 0x100>; /* Look-up table RAM */ > + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>, > + <&tegra_car TEGRA124_CLK_DFLL_REF>, > + <&tegra_car TEGRA124_CLK_I2C5>; If this controls I2C5 now, should it be documented that we can't use this controller in software while it is in use by DFLL? Thierry
On Thu, Feb 12, 2015 at 11:42:44PM +0100, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Thu, Jan 08, 2015 at 03:22:04PM +0200, Mikko Perttunen wrote: > > From: Tuomas Tynkkynen <ttynkkynen@nvidia.com> > > > > The DFLL is the main clocksource for the fast CPU cluster on Tegra124 > > and also provides automatic CPU rail voltage scaling as well. The DFLL > > is a separate IP block from the usual Tegra124 clock-and-reset > > controller, so it gets its own node in the device tree. > > > > Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> > > Signed-off-by: Mikko Perttunen <mikko.perttunen@kapsi.fi> > > --- > > .../bindings/clock/nvidia,tegra124-dfll.txt | 69 ++++++++++++++++++++++ > > 1 file changed, 69 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt > > > > diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt > > new file mode 100644 > > index 0000000..54c62ac > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt > > @@ -0,0 +1,69 @@ > > +NVIDIA Tegra124 DFLL FCPU clocksource > > + > > +This binding uses the common clock binding: > > +Documentation/devicetree/bindings/clock/clock-bindings.txt > > + > > +The DFLL IP block on Tegra is a root clocksource designed for clocking > > +the fast CPU cluster. It consists of a free-running voltage controlled > > +oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop > > +control module that will automatically adjust the VDD_CPU voltage by > > +communicating with an off-chip PMIC either via an I2C bus or via PWM signals. > > How would PWM communication work? The documentation below doesn't > describe it, so perhaps either leave that part out until the binding is > updated to support it, or maybe make an explicit note that this mode of > operation isn't supported yet? > > > +Required properties: > > +- compatible : should be "nvidia,tegra124-dfll-fcpu" > > +- reg : Defines the following set of registers, in the order listed: > > + - registers for the DFLL control logic. > > + - registers for the I2C output logic. > > + - registers for the integrated I2C master controller. > > + - look-up table RAM for voltage register values. > > Why do these all need to be separate sets? According to the TRM this is > a single IP block with a single register region, why the need to split > them apart? > > > +- interrupts: Should contain the DFLL block interrupt. > > +- 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: > > + - soc: Clock source for the DFLL control logic. > > + - ref: The closed loop reference clock > > + - i2c: Clock source for the integrated I2C master. > > +- #clock-cells: Must be 0. > > +- clock-output-names: Name of the clock output. > > +- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL > > + hardware will start controlling. > > How does the hardware control it? How do we go from regulator phandle to > something that the hardware will know how to access? > > > +Required properties for the control loop parameters: > > +- nvidia,sample-rate: Sample rate of the DFLL control loop. > > +- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM. > > +- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM. > > +- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM. > > +- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM. > > +- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM. > > +- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM. > > + > > +Required properties for I2C mode: > > +- nvidia,i2c-fs-rate: I2C transfer rate, if using FS mode. > > What's FS mode? > > > + > > +Example: > > + > > +dfll@0,70110000 { > > Perhaps this should be "clock@0,70110000"? > > > + compatible = "nvidia,tegra124-dfll"; > > + reg = <0 0x70110000 0 0x100>, /* DFLL control */ > > + <0 0x70110000 0 0x100>, /* I2C output control */ > > + <0 0x70110100 0 0x100>, /* Integrated I2C controller */ > > + <0 0x70110200 0 0x100>; /* Look-up table RAM */ > > + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; > > + clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>, > > + <&tegra_car TEGRA124_CLK_DFLL_REF>, > > + <&tegra_car TEGRA124_CLK_I2C5>; > > If this controls I2C5 now, should it be documented that we can't use > this controller in software while it is in use by DFLL? It doesn't control I2C5. However, I2C5 and the dfll I2C controller control the same pins. There is some arbitration logic which prevents both controllers driving the pins at the same time. This logic does not have a sw interface. However, this logic doesn't work if I2C5 is not clocked. So once the dfll is enabled, I2C5 must always be clocked. Cheers, Peter.
On 02/13/2015 12:42 AM, Thierry Reding wrote: > On Thu, Jan 08, 2015 at 03:22:04PM +0200, Mikko Perttunen wrote: >> From: Tuomas Tynkkynen <ttynkkynen@nvidia.com> >> >> The DFLL is the main clocksource for the fast CPU cluster on Tegra124 >> and also provides automatic CPU rail voltage scaling as well. The DFLL >> is a separate IP block from the usual Tegra124 clock-and-reset >> controller, so it gets its own node in the device tree. >> >> Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> >> Signed-off-by: Mikko Perttunen <mikko.perttunen@kapsi.fi> >> --- >> .../bindings/clock/nvidia,tegra124-dfll.txt | 69 ++++++++++++++++++++++ >> 1 file changed, 69 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt >> >> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt >> new file mode 100644 >> index 0000000..54c62ac >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt >> @@ -0,0 +1,69 @@ >> +NVIDIA Tegra124 DFLL FCPU clocksource >> + >> +This binding uses the common clock binding: >> +Documentation/devicetree/bindings/clock/clock-bindings.txt >> + >> +The DFLL IP block on Tegra is a root clocksource designed for clocking >> +the fast CPU cluster. It consists of a free-running voltage controlled >> +oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop >> +control module that will automatically adjust the VDD_CPU voltage by >> +communicating with an off-chip PMIC either via an I2C bus or via PWM signals. > > How would PWM communication work? The documentation below doesn't > describe it, so perhaps either leave that part out until the binding is > updated to support it, or maybe make an explicit note that this mode of > operation isn't supported yet? Yes, I'll edit this part. > >> +Required properties: >> +- compatible : should be "nvidia,tegra124-dfll-fcpu" >> +- reg : Defines the following set of registers, in the order listed: >> + - registers for the DFLL control logic. >> + - registers for the I2C output logic. >> + - registers for the integrated I2C master controller. >> + - look-up table RAM for voltage register values. > > Why do these all need to be separate sets? According to the TRM this is > a single IP block with a single register region, why the need to split > them apart? I will have to check with Tuomas if he had a reason to do it this way. > >> +- interrupts: Should contain the DFLL block interrupt. >> +- 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: >> + - soc: Clock source for the DFLL control logic. >> + - ref: The closed loop reference clock >> + - i2c: Clock source for the integrated I2C master. >> +- #clock-cells: Must be 0. >> +- clock-output-names: Name of the clock output. >> +- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL >> + hardware will start controlling. > > How does the hardware control it? How do we go from regulator phandle to > something that the hardware will know how to access? Looks like this property doesn't exist in the current device tree, along with some other properties. The compatible-string noted above is wrong too. I'll fix these for the next version. > >> +Required properties for the control loop parameters: >> +- nvidia,sample-rate: Sample rate of the DFLL control loop. >> +- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM. >> +- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM. >> +- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM. >> +- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM. >> +- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM. >> +- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM. >> + >> +Required properties for I2C mode: >> +- nvidia,i2c-fs-rate: I2C transfer rate, if using FS mode. > > What's FS mode? I would imagine it stands for full speed. I'll expand the abbreviation. > >> + >> +Example: >> + >> +dfll@0,70110000 { > > Perhaps this should be "clock@0,70110000"? Probably. > >> + compatible = "nvidia,tegra124-dfll"; >> + reg = <0 0x70110000 0 0x100>, /* DFLL control */ >> + <0 0x70110000 0 0x100>, /* I2C output control */ >> + <0 0x70110100 0 0x100>, /* Integrated I2C controller */ >> + <0 0x70110200 0 0x100>; /* Look-up table RAM */ >> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; >> + clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>, >> + <&tegra_car TEGRA124_CLK_DFLL_REF>, >> + <&tegra_car TEGRA124_CLK_I2C5>; > > If this controls I2C5 now, should it be documented that we can't use > this controller in software while it is in use by DFLL? I'll add a note about this. > > Thierry > Cheers, Mikko.
On 02/12/2015 03:54 PM, Peter De Schrijver wrote: > On Thu, Jan 08, 2015 at 03:22:04PM +0200, Mikko Perttunen wrote: >> From: Tuomas Tynkkynen <ttynkkynen@nvidia.com> >> >> The DFLL is the main clocksource for the fast CPU cluster on Tegra124 >> and also provides automatic CPU rail voltage scaling as well. The DFLL >> is a separate IP block from the usual Tegra124 clock-and-reset >> controller, so it gets its own node in the device tree. >> > > Please add devicetree@vger.kernel.org to the next CC list. Will do. Thanks for the acks! > > Peter. > -- > To unsubscribe from this list: send the line "unsubscribe linux-tegra" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
On 02/13/2015 12:42 AM, Thierry Reding wrote: > On Thu, Jan 08, 2015 at 03:22:04PM +0200, Mikko Perttunen wrote: >> From: Tuomas Tynkkynen <ttynkkynen@nvidia.com> >> >> The DFLL is the main clocksource for the fast CPU cluster on Tegra124 >> and also provides automatic CPU rail voltage scaling as well. The DFLL >> is a separate IP block from the usual Tegra124 clock-and-reset >> controller, so it gets its own node in the device tree. >> >> Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> >> Signed-off-by: Mikko Perttunen <mikko.perttunen@kapsi.fi> >> --- >> .../bindings/clock/nvidia,tegra124-dfll.txt | 69 ++++++++++++++++++++++ >> 1 file changed, 69 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt >> ... >> +Required properties: >> +- compatible : should be "nvidia,tegra124-dfll-fcpu" >> +- reg : Defines the following set of registers, in the order listed: >> + - registers for the DFLL control logic. >> + - registers for the I2C output logic. >> + - registers for the integrated I2C master controller. >> + - look-up table RAM for voltage register values. > > Why do these all need to be separate sets? According to the TRM this is > a single IP block with a single register region, why the need to split > them apart? On Tegra132, some of those register blocks (IIRC the first one) has moved to a different place (somewhere in the CAR register area). The TRM description indeed gives a single list of registers for the Tegra124 implementation of the DFLL. The split into 4 blocks was to make the binding more future-proof and to be closer to the real hardware design.
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt new file mode 100644 index 0000000..54c62ac --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt @@ -0,0 +1,69 @@ +NVIDIA Tegra124 DFLL FCPU clocksource + +This binding uses the common clock binding: +Documentation/devicetree/bindings/clock/clock-bindings.txt + +The DFLL IP block on Tegra is a root clocksource designed for clocking +the fast CPU cluster. It consists of a free-running voltage controlled +oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop +control module that will automatically adjust the VDD_CPU voltage by +communicating with an off-chip PMIC either via an I2C bus or via PWM signals. + +Required properties: +- compatible : should be "nvidia,tegra124-dfll-fcpu" +- reg : Defines the following set of registers, in the order listed: + - registers for the DFLL control logic. + - registers for the I2C output logic. + - registers for the integrated I2C master controller. + - look-up table RAM for voltage register values. +- interrupts: Should contain the DFLL block interrupt. +- 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: + - soc: Clock source for the DFLL control logic. + - ref: The closed loop reference clock + - i2c: Clock source for the integrated I2C master. +- #clock-cells: Must be 0. +- clock-output-names: Name of the clock output. +- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL + hardware will start controlling. + +Required properties for the control loop parameters: +- nvidia,sample-rate: Sample rate of the DFLL control loop. +- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM. +- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM. +- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM. +- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM. +- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM. +- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM. + +Required properties for I2C mode: +- nvidia,i2c-fs-rate: I2C transfer rate, if using FS mode. + +Example: + +dfll@0,70110000 { + compatible = "nvidia,tegra124-dfll"; + reg = <0 0x70110000 0 0x100>, /* DFLL control */ + <0 0x70110000 0 0x100>, /* I2C output control */ + <0 0x70110100 0 0x100>, /* Integrated I2C controller */ + <0 0x70110200 0 0x100>; /* Look-up table RAM */ + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>, + <&tegra_car TEGRA124_CLK_DFLL_REF>, + <&tegra_car TEGRA124_CLK_I2C5>; + clock-names = "soc", "ref", "i2c"; + #clock-cells = <0>; + clock-output-names = "dfllCPU_out"; + vdd-cpu-supply = <&vdd_cpu>; + status = "okay"; + + nvidia,sample-rate = <12500>; + nvidia,droop-ctrl = <0x00000f00>; + nvidia,force-mode = <1>; + nvidia,cf = <10>; + nvidia,ci = <0>; + nvidia,cg = <2>; + + nvidia,i2c-fs-rate = <400000>; +};