Re: [PATCH v3] ARM: tegra: Correct which USB controller has the UTMI pad registers
On 04/03/2015 10:21 AM, Tomeu Vizoso wrote:
It should be the first controller, not the second. The indexes of the
usb resets were also wrong and have been fixed.
The issue was caused by the changes in 308efde (ARM: tegra: Add resets
has-utmi-pad-registers flag to all USB PHYs) being misapplied by git
due to the patch context being insufficient.
This broke USB after 6261b06 (regulator: Defer lookup of supply to
regulator_get), because it changed the order in which the controllers
were probed.
The fix for this issue was suggested by Mikko Perttunen and Tuomas
Tynkkynen.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
Cc: Mikko Perttunen mikko.perttu...@kapsi.fi
Cc: Tuomas Tynkkynen ttynkky...@nvidia.com
---
Hi,
hope I have gotten it right this time, but please do check :)
Yeah, this seems correct to me :)
Thanks,
Tomeu
---
arch/arm/boot/dts/tegra124.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index cf01c81..13cc7ca 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -809,114 +809,114 @@
compatible = nvidia,tegra124-ehci, nvidia,tegra30-ehci,
usb-ehci;
reg = 0x0 0x7d00 0x0 0x4000;
interrupts = GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USBD;
resets = tegra_car 22;
reset-names = usb;
nvidia,phy = phy1;
status = disabled;
};
phy1: usb-phy@0,7d00 {
compatible = nvidia,tegra124-usb-phy,
nvidia,tegra30-usb-phy;
reg = 0x0 0x7d00 0x0 0x4000,
0x0 0x7d00 0x0 0x4000;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USBD,
tegra_car TEGRA124_CLK_PLL_U,
tegra_car TEGRA124_CLK_USBD;
clock-names = reg, pll_u, utmi-pads;
- resets = tegra_car 59, tegra_car 22;
+ resets = tegra_car 22, tegra_car 22;
reset-names = usb, utmi-pads;
nvidia,hssync-start-delay = 0;
nvidia,idle-wait-delay = 17;
nvidia,elastic-limit = 16;
nvidia,term-range-adj = 6;
nvidia,xcvr-setup = 9;
nvidia,xcvr-lsfslew = 0;
nvidia,xcvr-lsrslew = 3;
nvidia,hssquelch-level = 2;
nvidia,hsdiscon-level = 5;
nvidia,xcvr-hsslew = 12;
+ nvidia,has-utmi-pad-registers;
status = disabled;
};
usb@0,7d004000 {
compatible = nvidia,tegra124-ehci, nvidia,tegra30-ehci,
usb-ehci;
reg = 0x0 0x7d004000 0x0 0x4000;
interrupts = GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USB2;
resets = tegra_car 58;
reset-names = usb;
nvidia,phy = phy2;
status = disabled;
};
phy2: usb-phy@0,7d004000 {
compatible = nvidia,tegra124-usb-phy,
nvidia,tegra30-usb-phy;
reg = 0x0 0x7d004000 0x0 0x4000,
0x0 0x7d00 0x0 0x4000;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USB2,
tegra_car TEGRA124_CLK_PLL_U,
tegra_car TEGRA124_CLK_USBD;
clock-names = reg, pll_u, utmi-pads;
- resets = tegra_car 22, tegra_car 22;
+ resets = tegra_car 58, tegra_car 22;
reset-names = usb, utmi-pads;
nvidia,hssync-start-delay = 0;
nvidia,idle-wait-delay = 17;
nvidia,elastic-limit = 16;
nvidia,term-range-adj = 6;
nvidia,xcvr-setup = 9;
nvidia,xcvr-lsfslew = 0;
nvidia,xcvr-lsrslew = 3;
nvidia,hssquelch-level = 2;
nvidia,hsdiscon-level = 5;
nvidia,xcvr-hsslew = 12;
- nvidia,has-utmi-pad-registers;
status = disabled;
};
usb@0,7d008000 {
compatible = nvidia,tegra124-ehci, nvidia,tegra30-ehci,
usb-ehci;
reg = 0x0 0x7d008000 0x0 0x4000;
interrupts = GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USB3;
resets = tegra_car 59;
reset-names = usb;
nvidia,phy = phy3;
status = disabled;
};
phy3: usb-phy@0,7d008000 {
compatible = nvidia,tegra124-usb-phy,
nvidia,tegra30-usb-phy;
reg = 0x0 0x7d008000 0x0 0x4000,
0x0 0x7d00 0x0 0x4000
Re: [PATCH v2] ARM: tegra: Correct which USB controller has the UTMI pad registers
Reviewed-by: Mikko Perttunen mikko.perttu...@kapsi.fi
On 04/02/2015 06:00 PM, Tomeu Vizoso wrote:
It should be the first controller, not the second.
This broke USB after 6261b06 (regulator: Defer lookup of supply to
regulator_get), because it changed the order in which the controllers
were probed.
The fix for this issue was suggested by Mikko Perttunen.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
Cc: Mikko Perttunen mikko.perttu...@kapsi.fi
---
I think that the line numbers should be enough in this case, as I expect this
to be merged soon, but just in case I'm sending the same patch with plenty of
context.
Regards,
Tomeu
---
arch/arm/boot/dts/tegra124.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index cf01c81..cb786a9 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -821,77 +821,77 @@
compatible = nvidia,tegra124-usb-phy,
nvidia,tegra30-usb-phy;
reg = 0x0 0x7d00 0x0 0x4000,
0x0 0x7d00 0x0 0x4000;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USBD,
tegra_car TEGRA124_CLK_PLL_U,
tegra_car TEGRA124_CLK_USBD;
clock-names = reg, pll_u, utmi-pads;
resets = tegra_car 59, tegra_car 22;
reset-names = usb, utmi-pads;
nvidia,hssync-start-delay = 0;
nvidia,idle-wait-delay = 17;
nvidia,elastic-limit = 16;
nvidia,term-range-adj = 6;
nvidia,xcvr-setup = 9;
nvidia,xcvr-lsfslew = 0;
nvidia,xcvr-lsrslew = 3;
nvidia,hssquelch-level = 2;
nvidia,hsdiscon-level = 5;
nvidia,xcvr-hsslew = 12;
+ nvidia,has-utmi-pad-registers;
status = disabled;
};
usb@0,7d004000 {
compatible = nvidia,tegra124-ehci, nvidia,tegra30-ehci,
usb-ehci;
reg = 0x0 0x7d004000 0x0 0x4000;
interrupts = GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USB2;
resets = tegra_car 58;
reset-names = usb;
nvidia,phy = phy2;
status = disabled;
};
phy2: usb-phy@0,7d004000 {
compatible = nvidia,tegra124-usb-phy,
nvidia,tegra30-usb-phy;
reg = 0x0 0x7d004000 0x0 0x4000,
0x0 0x7d00 0x0 0x4000;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USB2,
tegra_car TEGRA124_CLK_PLL_U,
tegra_car TEGRA124_CLK_USBD;
clock-names = reg, pll_u, utmi-pads;
resets = tegra_car 22, tegra_car 22;
reset-names = usb, utmi-pads;
nvidia,hssync-start-delay = 0;
nvidia,idle-wait-delay = 17;
nvidia,elastic-limit = 16;
nvidia,term-range-adj = 6;
nvidia,xcvr-setup = 9;
nvidia,xcvr-lsfslew = 0;
nvidia,xcvr-lsrslew = 3;
nvidia,hssquelch-level = 2;
nvidia,hsdiscon-level = 5;
nvidia,xcvr-hsslew = 12;
- nvidia,has-utmi-pad-registers;
status = disabled;
};
usb@0,7d008000 {
compatible = nvidia,tegra124-ehci, nvidia,tegra30-ehci,
usb-ehci;
reg = 0x0 0x7d008000 0x0 0x4000;
interrupts = GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USB3;
resets = tegra_car 59;
reset-names = usb;
nvidia,phy = phy3;
status = disabled;
};
phy3: usb-phy@0,7d008000 {
compatible = nvidia,tegra124-usb-phy,
nvidia,tegra30-usb-phy;
reg = 0x0 0x7d008000 0x0 0x4000,
0x0 0x7d00 0x0 0x4000;
phy_type = utmi;
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: tegra: Correct which USB controller has the UTMI pad registers
On 04/02/2015 06:20 PM, Mikko Perttunen wrote:
Reviewed-by: Mikko Perttunen mikko.perttu...@kapsi.fi
Scratch that;
as Tuomas noted on IRC, the reset numbers here are still wrong.
phy1 should have 22 and phy2 58.
On 04/02/2015 06:00 PM, Tomeu Vizoso wrote:
It should be the first controller, not the second.
This broke USB after 6261b06 (regulator: Defer lookup of supply to
regulator_get), because it changed the order in which the controllers
were probed.
The fix for this issue was suggested by Mikko Perttunen.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
Cc: Mikko Perttunen mikko.perttu...@kapsi.fi
---
I think that the line numbers should be enough in this case, as I
expect this to be merged soon, but just in case I'm sending the same
patch with plenty of context.
Regards,
Tomeu
---
arch/arm/boot/dts/tegra124.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra124.dtsi
b/arch/arm/boot/dts/tegra124.dtsi
index cf01c81..cb786a9 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -821,77 +821,77 @@
compatible = nvidia,tegra124-usb-phy,
nvidia,tegra30-usb-phy;
reg = 0x0 0x7d00 0x0 0x4000,
0x0 0x7d00 0x0 0x4000;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USBD,
tegra_car TEGRA124_CLK_PLL_U,
tegra_car TEGRA124_CLK_USBD;
clock-names = reg, pll_u, utmi-pads;
resets = tegra_car 59, tegra_car 22;
reset-names = usb, utmi-pads;
nvidia,hssync-start-delay = 0;
nvidia,idle-wait-delay = 17;
nvidia,elastic-limit = 16;
nvidia,term-range-adj = 6;
nvidia,xcvr-setup = 9;
nvidia,xcvr-lsfslew = 0;
nvidia,xcvr-lsrslew = 3;
nvidia,hssquelch-level = 2;
nvidia,hsdiscon-level = 5;
nvidia,xcvr-hsslew = 12;
+nvidia,has-utmi-pad-registers;
status = disabled;
};
usb@0,7d004000 {
compatible = nvidia,tegra124-ehci, nvidia,tegra30-ehci,
usb-ehci;
reg = 0x0 0x7d004000 0x0 0x4000;
interrupts = GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USB2;
resets = tegra_car 58;
reset-names = usb;
nvidia,phy = phy2;
status = disabled;
};
phy2: usb-phy@0,7d004000 {
compatible = nvidia,tegra124-usb-phy,
nvidia,tegra30-usb-phy;
reg = 0x0 0x7d004000 0x0 0x4000,
0x0 0x7d00 0x0 0x4000;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USB2,
tegra_car TEGRA124_CLK_PLL_U,
tegra_car TEGRA124_CLK_USBD;
clock-names = reg, pll_u, utmi-pads;
resets = tegra_car 22, tegra_car 22;
reset-names = usb, utmi-pads;
nvidia,hssync-start-delay = 0;
nvidia,idle-wait-delay = 17;
nvidia,elastic-limit = 16;
nvidia,term-range-adj = 6;
nvidia,xcvr-setup = 9;
nvidia,xcvr-lsfslew = 0;
nvidia,xcvr-lsrslew = 3;
nvidia,hssquelch-level = 2;
nvidia,hsdiscon-level = 5;
nvidia,xcvr-hsslew = 12;
-nvidia,has-utmi-pad-registers;
status = disabled;
};
usb@0,7d008000 {
compatible = nvidia,tegra124-ehci, nvidia,tegra30-ehci,
usb-ehci;
reg = 0x0 0x7d008000 0x0 0x4000;
interrupts = GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH;
phy_type = utmi;
clocks = tegra_car TEGRA124_CLK_USB3;
resets = tegra_car 59;
reset-names = usb;
nvidia,phy = phy3;
status = disabled;
};
phy3: usb-phy@0,7d008000 {
compatible = nvidia,tegra124-usb-phy,
nvidia,tegra30-usb-phy;
reg = 0x0 0x7d008000 0x0 0x4000,
0x0 0x7d00 0x0 0x4000;
phy_type = utmi;
--
To unsubscribe from this list: send the line unsubscribe linux-tegra in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: tegra: Correct which USB controller has the UTMI pad registers
Have you checked that this patch applies correctly, considering that the chunks are still ambiguous? :) Mikko On 04/02/2015 05:31 PM, Tomeu Vizoso wrote: It should be the first controller, not the second. This broke USB after 6261b06 (regulator: Defer lookup of supply to regulator_get), because it changed the order in which the controllers were probed. The fix for this issue was suggested by Mikko Perttunen. Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com Cc: Mikko Perttunen mikko.perttu...@kapsi.fi --- arch/arm/boot/dts/tegra124.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi index cf01c81..cb786a9 100644 --- a/arch/arm/boot/dts/tegra124.dtsi +++ b/arch/arm/boot/dts/tegra124.dtsi @@ -838,6 +838,7 @@ nvidia,hssquelch-level = 2; nvidia,hsdiscon-level = 5; nvidia,xcvr-hsslew = 12; + nvidia,has-utmi-pad-registers; status = disabled; }; @@ -874,7 +875,6 @@ nvidia,hssquelch-level = 2; nvidia,hsdiscon-level = 5; nvidia,xcvr-hsslew = 12; - nvidia,has-utmi-pad-registers; status = disabled; }; -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 06/15] of: Add Tegra124 EMC bindings
On 03/02/2015 10:47 AM, Alexandre Courbot wrote: On Thu, Feb 12, 2015 at 11:06 PM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: From: Mikko Perttunen mperttu...@nvidia.com Add binding documentation for the nvidia,tegra124-emc device tree node. Signed-off-by: Mikko Perttunen mperttu...@nvidia.com Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com --- v5: * Add a short description for each of the register properties v4: * Remove mandatory naming of the timings subnode * Remove constraint on the unit-address of the timings and timing subnodes * Add some more information about nvidia,emc-configuration * Make the example complete v2: * Specify the unit addresses for the timings and timing nodes --- .../bindings/memory-controllers/tegra-emc.txt | 379 + 1 file changed, 379 insertions(+) create mode 100644 Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt diff --git a/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt b/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt new file mode 100644 index 000..da923b1 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt @@ -0,0 +1,379 @@ +NVIDIA Tegra124 SoC EMC (external memory controller) + + +Required properties : +- compatible : Should be nvidia,tegra124-emc. +- reg : physical base address and length of the controller's registers. +- nvidia,memory-controller : phandle of the MC driver. + +The node should contain a emc-timings subnode for each supported RAM type (see field RAM_CODE in +register PMC_STRAPPING_OPT_A), with its unit address being its RAM_CODE. + +Required properties for emc-timings nodes : +- nvidia,ram-code : Should contain the value of RAM_CODE this timing set is used for. + +Each emc-timings node should contain a timing subnode for every supported EMC clock rate. The +timing subnodes should have the clock rate in Hz as their unit address. + +Required properties for timing nodes : +- clock-frequency : Should contain the memory clock rate in Hz. +- The following properties contain EMC timing characterization values (specified in the board +documentation) : + - nvidia,emc-auto-cal-config : EMC_AUTO_CAL_CONFIG + - nvidia,emc-auto-cal-config2 : EMC_AUTO_CAL_CONFIG2 + - nvidia,emc-auto-cal-config3 : EMC_AUTO_CAL_CONFIG3 + - nvidia,emc-auto-cal-interval : EMC_AUTO_CAL_INTERVAL + - nvidia,emc-bgbias-ctl0 : EMC_BGBIAS_CTL0 + - nvidia,emc-cfg : EMC_CFG + - nvidia,emc-cfg-2 : EMC_CFG_2 + - nvidia,emc-cfg-dig-dll : EMC_CFG_DIG_DLL + - nvidia,emc-ctt-term-ctrl : EMC_CTT_TERM_CTRL + - nvidia,emc-mode-1 : Mode Register 1 + - nvidia,emc-mode-2 : Mode Register 2 + - nvidia,emc-mode-4 : Mode Register 4 + - nvidia,emc-mode-reset : Mode Register 0 + - nvidia,emc-mrs-wait-cnt : EMC_MRS_WAIT_CNT + - nvidia,emc-sel-dpd-ctrl : EMC_SEL_DPD_CTRL + - nvidia,emc-xm2dqspadctrl2 : EMC_XM2DQSPADCTRL2 + - nvidia,emc-zcal-cnt-long : EMC_ZCAL_WAIT_CNT + - nvidia,emc-zcal-interval : EMC_ZCAL_INTERVAL +- nvidia,emc-configuration : EMC timing characterization data. These are the registers (see section +15.6.2 EMC Registers in the TRM) whose values need to be specified, according to the board +documentation: I'm a little bit confused by this. On the one hand, some registers are defined by dedicated DT properties, and on the other some are simply specified in the nvidia,emc-configuration array. I guess the rationale for this is to isolate the registers whose value may control the driver vs. those that simply needs to be written as-is. But in this case, why are some registers (like EMC_CFG_DIG_DLL) present in both lists, sometimes with different values? In the case of EMC_CFG_DIG_DLL, I also see that the read value of nvidia,emc-cfg-dig-dll seems to never be used anywhere in tegra124-emc.c. Should this property exist at all? Note that I have only checked this one, there might be others in the same case. Or maybe I completely misunderstood the intent here, in which case, please enlighten me. :) Well spotted! Looks like the nvidia,emc-cfg-dig-dll property should not be there. The list was essentially copied from the downstream kernel; looks like there the list of variables was probably based on that of Tegra148, where the cfg-dig-dll seems to be used. (The downstream Tegra124 does not use it.) Should check this for the other properties as well. Mikko -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 13/18] cpufreq: tegra124: Add device tree bindings
From: Tuomas Tynkkynen ttynkky...@nvidia.com
The cpufreq driver for Tegra124 will be a different one than the old
Tegra20 cpufreq driver (tegra-cpufreq), which does not use the device
tree.
Signed-off-by: Tuomas Tynkkynen ttynkky...@nvidia.com
Signed-off-by: Mikko Perttunen mikko.perttu...@kapsi.fi
Cc: devicetree@vger.kernel.org
---
.../bindings/cpufreq/tegra124-cpufreq.txt | 44 ++
1 file changed, 44 insertions(+)
create mode 100644
Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
b/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
new file mode 100644
index 000..b1669fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
@@ -0,0 +1,44 @@
+Tegra124 CPU frequency scaling driver bindings
+--
+
+Both required and optional properties listed below must be defined
+under node /cpus/cpu@0.
+
+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:
+ - cpu_g: Clock mux for the fast CPU cluster.
+ - cpu_lp: Clock mux for the low-power CPU cluster.
+ - pll_x: Fast PLL clocksource.
+ - pll_p: Auxiliary PLL used during fast PLL rate changes.
+ - dfll: Fast DFLL clocksource that also automatically scales CPU voltage.
+- vdd-cpu-supply: Regulator for CPU voltage
+
+Optional properties:
+- clock-latency: Specify the possible maximum transition latency for clock,
+ in unit of nanoseconds.
+
+Example:
+
+cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a15;
+ reg = 0;
+
+ clocks = tegra_car TEGRA124_CLK_CCLK_G,
+tegra_car TEGRA124_CLK_CCLK_LP,
+tegra_car TEGRA124_CLK_PLL_X,
+tegra_car TEGRA124_CLK_PLL_P,
+dfll;
+ clock-names = cpu_g, cpu_lp, pll_x, pll_p, dfll;
+ clock-latency = 30;
+ vdd-cpu-supply: vdd_cpu;
+ };
+
+ ...
+};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 01/18] clk: tegra: Add binding for the Tegra124 DFLL clocksource
From: Tuomas Tynkkynen ttynkky...@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 ttynkky...@nvidia.com
Signed-off-by: Mikko Perttunen mikko.perttu...@kapsi.fi
Cc: devicetree@vger.kernel.org
---
v8:
- Changed dfll@ - clock@
- Changed compatibility string to nvidia,tegra124-dfll
- Clarified how the vdd-cpu-supply property is used
- Marked nvidia,cg-scale as optional since it is a boolean property
- Expanded the 'FS mode' term to 'full speed mode'
- Added dvco reset control
.../bindings/clock/nvidia,tegra124-dfll.txt| 79 ++
1 file changed, 79 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 000..ee7e5fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
@@ -0,0 +1,79 @@
+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.
+Currently only the I2C mode is supported by these bindings.
+
+Required properties:
+- compatible : should be nvidia,tegra124-dfll
+- 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 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.
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+ - dvco: Reset control for the DFLL DVCO.
+- #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. The regulator will be queried for
+ the I2C register, control values and supported voltages.
+
+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.
+
+Optional properties for the control loop parameters:
+- 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 full speed mode.
+
+Example:
+
+clock@0,7011 {
+compatible = nvidia,tegra124-dfll;
+reg = 0 0x7011 0 0x100, /* DFLL control */
+ 0 0x7011 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;
+resets = tegra_car TEGRA124_RST_DFLL_DVCO;
+reset-names = dvco;
+#clock-cells = 0;
+clock-output-names = dfllCPU_out;
+vdd-cpu-supply = vdd_cpu;
+status = okay;
+
+nvidia,sample-rate = 12500;
+nvidia,droop-ctrl = 0x0f00;
+nvidia,force-mode = 1;
+nvidia,cf = 10;
+nvidia,ci = 0;
+nvidia,cg = 2;
+
+nvidia,i2c-fs-rate = 40;
+};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 1/1] thermal: of: improve of-thermal sensor registration API
On 11/18/2014 04:39 PM, Eduardo Valentin wrote: Different drivers request API extensions in of-thermal. For this reason, additional callbacks are required to fit the new drivers needs. The current API implementation expects the registering sensor driver to provide a get_temp and get_trend callbacks as function parameters. As the amount of callbacks is growing, this patch changes the existing implementation to use a .ops field to hold all the of thermal callbacks to sensor drivers. This patch also changes the existing of-thermal users to fit the new API design. No functional change is introduced in this patch. Cc: Alexandre Courbot gnu...@gmail.com Cc: devicetree@vger.kernel.org Cc: Grant Likely grant.lik...@linaro.org Cc: Guenter Roeck li...@roeck-us.net Cc: Jean Delvare jdelv...@suse.de Cc: linux-ker...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: lm-sens...@lm-sensors.org Cc: Rob Herring robh...@kernel.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Zhang Rui rui.zh...@intel.com Reviewed-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Eduardo Valentin edubez...@gmail.com --- drivers/hwmon/lm75.c | 9 +++-- drivers/hwmon/ntc_thermistor.c | 6 +++- drivers/hwmon/tmp102.c | 6 +++- drivers/thermal/of-thermal.c | 40 ++ drivers/thermal/tegra_soctherm.c | 7 ++-- drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 8 +++-- include/linux/thermal.h| 24 + 7 files changed, 63 insertions(+), 37 deletions(-) --- Difference from V3: - Keep the same behavior regarding callback checks. Change in behavior may be sent in a separate patch. Difference from V2: - Fix wrong assignment in tegra driver. Difference from V1: - Fix error handling when .get_trend is not provided. @@ -356,8 +356,8 @@ thermal_zone_of_add_sensor(struct device_node *zone, * than one sensors * @data: a private pointer (owned by the caller) that will be passed *back, when a temperature reading is needed. - * @get_temp: a pointer to a function that reads the sensor temperature. - * @get_trend: a pointer to a function that reads the sensor temperature trend. + * @ops: struct thermal_zone_of_device *. Must contain at least .get_trend and + * .get_temp. This comment seems to be incorrect, as .get_trend is optional. * * This function will search the list of thermal zones described in device * tree and look for the zone that refer to the sensor device pointed by With that minor one fixed, Tested-by: Mikko Perttunen mikko.perttu...@kapsi.fi Reviewed-by: Mikko Perttunen mikko.perttu...@kapsi.fi Cheers, Mikko -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 1/1] thermal: of: improve of-thermal sensor registration API
On 11/19/2014 05:41 PM, Mikko Perttunen wrote: On 11/18/2014 04:39 PM, Eduardo Valentin wrote: Different drivers request API extensions in of-thermal. For this reason, additional callbacks are required to fit the new drivers needs. The current API implementation expects the registering sensor driver to provide a get_temp and get_trend callbacks as function parameters. As the amount of callbacks is growing, this patch changes the existing implementation to use a .ops field to hold all the of thermal callbacks to sensor drivers. This patch also changes the existing of-thermal users to fit the new API design. No functional change is introduced in this patch. Cc: Alexandre Courbot gnu...@gmail.com Cc: devicetree@vger.kernel.org Cc: Grant Likely grant.lik...@linaro.org Cc: Guenter Roeck li...@roeck-us.net Cc: Jean Delvare jdelv...@suse.de Cc: linux-ker...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: lm-sens...@lm-sensors.org Cc: Rob Herring robh...@kernel.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Zhang Rui rui.zh...@intel.com Reviewed-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Eduardo Valentin edubez...@gmail.com --- drivers/hwmon/lm75.c | 9 +++-- drivers/hwmon/ntc_thermistor.c | 6 +++- drivers/hwmon/tmp102.c | 6 +++- drivers/thermal/of-thermal.c | 40 ++ drivers/thermal/tegra_soctherm.c | 7 ++-- drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 8 +++-- include/linux/thermal.h| 24 + 7 files changed, 63 insertions(+), 37 deletions(-) --- Difference from V3: - Keep the same behavior regarding callback checks. Change in behavior may be sent in a separate patch. Difference from V2: - Fix wrong assignment in tegra driver. Difference from V1: - Fix error handling when .get_trend is not provided. @@ -356,8 +356,8 @@ thermal_zone_of_add_sensor(struct device_node *zone, * than one sensors * @data: a private pointer (owned by the caller) that will be passed *back, when a temperature reading is needed. - * @get_temp: a pointer to a function that reads the sensor temperature. - * @get_trend: a pointer to a function that reads the sensor temperature trend. + * @ops: struct thermal_zone_of_device *. Must contain at least .get_trend and + * .get_temp. This comment seems to be incorrect, as .get_trend is optional. Also, the parameter is of type struct thermal_zone_of_device_ops *, not just thermal_zone_of_device. * * This function will search the list of thermal zones described in device * tree and look for the zone that refer to the sensor device pointed by With that minor one fixed, Tested-by: Mikko Perttunen mikko.perttu...@kapsi.fi Reviewed-by: Mikko Perttunen mikko.perttu...@kapsi.fi Cheers, Mikko -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/1] thermal: of: improve of-thermal sensor registration API
On 11/18/2014 12:44 AM, Eduardo Valentin wrote:
Different drivers request API extensions in of-thermal. For this reason,
additional callbacks are required to fit the new drivers needs.
The current API implementation expects the registering sensor driver
to provide a get_temp and get_trend callbacks as function parameters.
As the amount of callbacks is growing, this patch changes the existing
implementation to use a .ops field to hold all the of thermal callbacks
to sensor drivers.
This patch also changes the existing of-thermal users to fit the new
API design. No functional change is introduced in this patch.
Cc: Alexandre Courbot gnu...@gmail.com
Cc: devicetree@vger.kernel.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: Jean Delvare jdelv...@suse.de
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: lm-sens...@lm-sensors.org
Cc: Rob Herring robh...@kernel.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Zhang Rui rui.zh...@intel.com
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
Difference from V1:
- Fix error handling when .get_trend is not provided.
---
drivers/hwmon/lm75.c | 9 +++--
drivers/hwmon/ntc_thermistor.c | 6 +++-
drivers/hwmon/tmp102.c | 6 +++-
drivers/thermal/of-thermal.c | 41 +-
drivers/thermal/tegra_soctherm.c | 7 ++--
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 8 +++--
include/linux/thermal.h| 24 +
7 files changed, 62 insertions(+), 39 deletions(-)
...
diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c
index 70f7e9e..893c39c 100644
--- a/drivers/thermal/tegra_soctherm.c
+++ b/drivers/thermal/tegra_soctherm.c
@@ -317,6 +317,10 @@ static int tegra_thermctl_get_temp(void *data, long
*out_temp)
return 0;
}
+static const struct thermal_zone_of_device_ops tegra_of_thermal_ops = {
+ .get_trend = tegra_thermctl_get_temp,
+};
This should probably read .get_temp = tegra_thermctl_get_temp instead
of .get_trend :)
...
Cheers,
Mikko
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 10/13] memory: tegra: Add EMC (external memory controller) driver
On 11/12/2014 05:45 PM, Thierry Reding wrote:
On Wed, Nov 12, 2014 at 08:56:33AM +0100, Tomeu Vizoso wrote:
[...]
diff --git a/drivers/memory/tegra/tegra124-emc.c
b/drivers/memory/tegra/tegra124-emc.c
[...]
+static int t124_emc_burst_regs[] = {
The t124 prefix seems rather redundant in a Tegra124-specific file. Also
these should really be unsigned.
+struct emc_timing {
+ unsigned long rate;
+
+ /*
+* Store EMC burst data in a union to minimize mistakes. This allows
+* us to use the same burst data lists as used by the downstream and
+* ChromeOS kernels.
I don't understand what this means. Can you elaborate?
We could store the three specifically named u32's separately, but using
a union we can easily keep the indexing for the burst registers
identical to the indexing used in the downstream and ChromeOS kernels.
In reality, these burst register lists are generated by NVIDIA's
downstream tool, so allowing use of the same lists minimizes possible
(probably very difficult to spot) mistakes when porting mach
files/device trees from those kernels to the upstream kernel.
+*/
+ union {
+ u32 emc_burst_data[ARRAY_SIZE(t124_emc_burst_regs)];
+ struct {
+ u32 __pad0[121];
+ u32 emc_xm2dqspadctrl2;
+ u32 __pad1[15];
+ u32 emc_zcal_interval;
+ u32 __pad2[1];
+ u32 emc_mrs_wait_cnt;
+ };
+ };
[...]
+struct tegra_emc {
+ struct platform_device *pdev;
I don't see this ever used other than for accessing pdev-dev, in which
case it would be much simpler and save a lot of characters if this was
simply:
struct device *dev;
+ struct tegra_mc *mc;
+
+ void __iomem *emc_regs;
There is no second set of registers, so the emc_ prefix is useless.
+
+ enum emc_dram_type dram_type;
+ u8 dram_num;
Should be an unsized type and match what's returned by the MC accessor.
+
+ struct emc_timing last_timing;
struct emc_timing is rather big, can this be a pointer to an entry in
the timings array instead?
No. The timing set by the pre-kernel boot process might not correspond
to any timing in the kernel's timing lists. Of course, we don't need
most of the values at that point (and don't populate them either), so it
would be possible to special case the timing change function to use some
separate structure for the first timing change. Doing what is done now
is simpler, though. It is also how it's done downstream (not that that
is a good indicator of good design..)
+ struct emc_timing *timings;
+ unsigned int num_timings;
+};
+
+/* Timing change sequence functions */
+
+static void emc_ccfifo_writel(struct tegra_emc *tegra, u32 val,
+ unsigned long offs)
+{
+ writel(val, tegra-emc_regs + EMC_CCFIFO_DATA);
+ writel(offs, tegra-emc_regs + EMC_CCFIFO_ADDR);
+}
+
+static void emc_seq_update_timing(struct tegra_emc *tegra)
+{
+ int i;
unsigned int, please.
+
+ writel(1, tegra-emc_regs + EMC_TIMING_CONTROL);
+
+ for (i = 0; i EMC_STATUS_UPDATE_TIMEOUT; ++i) {
+ if (!(readl(tegra-emc_regs + EMC_STATUS)
+ EMC_STATUS_TIMING_UPDATE_STALLED))
+ return;
+ }
You're busy-looping 1000 times here. What are the real criteria here?
How long is this allowed to take? Should this not be a timed loop where
the number of iterations doesn't matter?
Logic directly taken from downstream/hw testing code. A timeout would
sound more logical, but dunno what to use.
+
+ dev_err(tegra-pdev-dev, timing update failed\n);
+}
Should this return an error that can be propagated?
I'm not sure if it's safe to stop during the timing change sequence.. at
least the downstream code doesn't try either. To know for sure, you'd
need some internal guy who really knows the sequence.
+static void emc_seq_disable_auto_cal(struct tegra_emc *tegra)
+{
+ int i;
+
+ writel(0, tegra-emc_regs + EMC_AUTO_CAL_INTERVAL);
+
+ for (i = 0; i EMC_STATUS_UPDATE_TIMEOUT; ++i) {
+ if (!(readl(tegra-emc_regs + EMC_AUTO_CAL_STATUS)
+ EMC_AUTO_CAL_STATUS_ACTIVE))
+ return;
+ }
+
+ dev_err(tegra-pdev-dev, auto cal disable failed\n);
+}
Same comments as for emc_seq_update_timing().
+
+static void emc_seq_wait_clkchange(struct tegra_emc *tegra)
+{
+ int i;
+
+ for (i = 0; i EMC_STATUS_UPDATE_TIMEOUT; ++i) {
+ if (readl(tegra-emc_regs + EMC_INTSTATUS)
+ EMC_INTSTATUS_CLKCHANGE_COMPLETE)
+ return;
+ }
+
+ dev_err(tegra-pdev-dev, clkchange failed\n);
+}
And again.
+
+static void emc_prepare_timing_change(struct tegra_emc *tegra,
+
Re: [PATCH v3 04/13] of: document new emc-timings subnode in nvidia,tegra124-car
To better facilitate discussion, here's an outline of how the driver works:
emc_set_rate (CAR) gets called
The current timing (= rate,parent pair) is checked along with the
target timing.
If the target timing has the same clock source (~parent, see
emc_parent_clk_sources in the clk driver), find a timing with a
different clock source. This is to prevent a situation where we
have switched to a new parent rate but the EMC has not yet been
reprogrammed. This new timing is called a backup timing.
If a backup timing was required, switch to it (using this same
procedure).
Set the rate of the new parent to the required rate and enable it. It
is important to use the correct parent for each timing, since in
addition to the rate requirements, there are jitter requirements.
The specified timings have been verified by a hardware team.
Call tegra_emc_prepare_timing_change. This does assorted things to
prepare the EMC block for a timing change and also tells the MC
driver to prepare for it.
Prepare the value that will be written to CLK_SOURCE_EMC in the CAR
block. This value contains the divisor to get from the parent rate
to the EMC rate and specifies the parent clock to use.
Write the value. This must be done in a single write, as it starts a
state machine that uses the written value.
Call tegra_emc_complete_timing_change. This will lead the state
machine to completion.
Tell CCF that our parent is now the specified one.
Disable the old parent.
Note that information about the parent is only needed within the CAR
driver and not in EMC or MC.
Those drivers only need to map the EMC rate to a set of configuration
values.
If the parent clock information is moved under the EMC node, we have
some options:
a) Add API to EMC that the CAR driver can use to query the parent
information.
b) Add API to CAR that the EMC driver can use to write the rate and
parent information.
c) Other?
Cheers,
Mikko.
On 11/07/2014 07:31 AM, Alexandre Courbot wrote:
On 11/07/2014 12:12 AM, Rob Herring wrote:
On Thu, Nov 6, 2014 at 12:37 AM, Alexandre Courbot
acour...@nvidia.com wrote:
On 10/30/2014 01:22 AM, Tomeu Vizoso wrote:
The EMC clock needs some extra information for changing its rate.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
.../bindings/clock/nvidia,tegra124-car.txt | 46
+-
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
index ded5d62..42e0588 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
@@ -19,12 +19,35 @@ Required properties :
In clock consumers, this cell represents the bit number in the
CAR's
array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
+The node should contain a emc-timings subnode for each supported RAM
type (see
+field RAM_CODE in register PMC_STRAPPING_OPT_A), with its unit address
being its
+RAM_CODE.
+
+Required properties for emc-timings nodes :
+- nvidia,ram-code : Should contain the value of RAM_CODE this
timing set
+ is used for.
+
+Each emc-timings node should contain a timing subnode for every
supported
+EMC clock rate. The timing subnodes should have the clock rate in
Hz as
their
+unit address.
This seems to be a quite liberal use of unit addresses (same in the next
patch) - is this allowed by DT?
No, unit address should match a reg property.
Mmm, would you have any suggestion as to how this can be fixed? Right
now what I can think of is either to replace the clock-frequency
property by reg (which would be confusing), or to use a different
naming scheme, e.g. timing-1275. IIUC the naming is not essential
for properly parsing these nodes, so maybe the second solution is the
way to go?
+
+Required properties for timing nodes :
+- clock-frequency : Should contain the memory clock rate to which this
timing
+relates.
+- nvidia,parent-clock-frequency : Should contain the rate at which the
current
+parent of the EMC clock should be running at this timing.
+- 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:
+ - emc-parent : the clock that should be the parent of the EMC
clock at
this
+timing.
+
Example SoC include file:
/ {
- tegra_car: clock {
+ tegra_car: clock@0,60006000 {
The comma here is wrong. Commas should be used when you have something
like PCI bus:dev:func for addressing.
compatible = nvidia,tegra124-car;
- reg = 0x60006000 0x1000;
+ reg = 0x0 0x60006000 0x0 0x1000;
The number of cell's is really irrelevant to the example.
#clock-cells = 1;
#reset-cells = 1;
};
@@ -60,4
Re: [PATCH v3 10/13] memory: tegra: Add EMC (external memory controller) driver
On 11/06/2014 09:56 AM, Alexandre Courbot wrote: On 10/30/2014 01:22 AM, Tomeu Vizoso wrote: From: Mikko Perttunen mperttu...@nvidia.com Implements functionality needed to change the rate of the memory bus clock. Signed-off-by: Mikko Perttunen mperttu...@nvidia.com Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com --- v2:* Use subsys_initcall(), so it gets probed after the MC driver and before the CAR driver --- drivers/memory/Kconfig | 10 + drivers/memory/Makefile |1 - drivers/memory/tegra/Makefile |1 + drivers/memory/tegra/tegra124-emc.c | 1133 +++ include/soc/tegra/memory.h |2 + 5 files changed, 1146 insertions(+), 1 deletion(-) create mode 100644 drivers/memory/tegra/tegra124-emc.c diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 6d91c27..3ba3aef 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -51,6 +51,16 @@ config MVEBU_DEVBUS Armada 370 and Armada XP. This controller allows to handle flash devices such as NOR, NAND, SRAM, and FPGA. +config TEGRA124_EMC +bool Tegra124 External Memory Controller driver +default y +depends on ARCH_TEGRA_124_SOC +help + This driver is for the External Memory Controller (EMC) found on + Tegra124 chips. The EMC controls the external DRAM on the board. + This driver is required to change memory timings / clock rate for + external memory. + config TEGRA20_MC bool Tegra20 Memory Controller(MC) driver default y diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index 1c932e7..8e5ec8d 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -12,5 +12,4 @@ obj-$(CONFIG_FSL_CORENET_CF)+= fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC)+= fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS)+= mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC)+= tegra20-mc.o - obj-$(CONFIG_ARCH_TEGRA)+= tegra/ diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile index 51b9e8f..4e84bef 100644 --- a/drivers/memory/tegra/Makefile +++ b/drivers/memory/tegra/Makefile @@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= tegra30-mc.o obj-$(CONFIG_ARCH_TEGRA_114_SOC)+= tegra114-mc.o obj-$(CONFIG_ARCH_TEGRA_124_SOC)+= tegra124-mc.o obj-$(CONFIG_ARCH_TEGRA_132_SOC)+= tegra124-mc.o +obj-$(CONFIG_TEGRA124_EMC)+= tegra124-emc.o diff --git a/drivers/memory/tegra/tegra124-emc.c b/drivers/memory/tegra/tegra124-emc.c new file mode 100644 index 000..8438de2 --- /dev/null +++ b/drivers/memory/tegra/tegra124-emc.c @@ -0,0 +1,1133 @@ +/* + * drivers/memory/tegra124-emc.c + * + * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved. + * + * Author: + *Mikko Perttunen mperttu...@nvidia.com + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include linux/clk-provider.h +#include linux/clk.h +#include linux/clkdev.h +#include linux/delay.h +#include linux/module.h +#include linux/of_address.h +#include linux/of_platform.h +#include linux/platform_device.h +#include linux/sort.h +#include linux/string.h + +#include soc/tegra/fuse.h +#include soc/tegra/memory.h + +#define EMC_FBIO_CFG50x104 +#defineEMC_FBIO_CFG5_DRAM_TYPE_MASK0x3 +#defineEMC_FBIO_CFG5_DRAM_TYPE_SHIFT0 + +#define EMC_INTSTATUS0x0 +#define EMC_INTSTATUS_CLKCHANGE_COMPLETEBIT(4) + +#define EMC_CFG0xc +#define EMC_CFG_DRAM_CLKSTOP_PDBIT(31) +#define EMC_CFG_DRAM_CLKSTOP_SRBIT(30) +#define EMC_CFG_DRAM_ACPDBIT(29) +#define EMC_CFG_DYN_SREFBIT(28) +#define EMC_CFG_PWR_MASK((0xF 28) | BIT(18)) +#define EMC_CFG_DSR_VTTGEN_DRV_ENBIT(18) + +#define EMC_REFCTRL0x20 +#define EMC_REFCTRL_DEV_SEL_SHIFT0 +#define EMC_REFCTRL_ENABLEBIT(31) + +#define EMC_TIMING_CONTROL0x28 +#define EMC_RC0x2c +#define EMC_RFC0x30 +#define EMC_RAS0x34 +#define EMC_RP0x38 +#define EMC_R2W0x3c +#define EMC_W2R0x40 +#define EMC_R2P0x44 +#define EMC_W2P0x48 +#define EMC_RD_RCD0x4c +#define EMC_WR_RCD0x50 +#define EMC_RRD0x54 +#define EMC_REXT0x58 +#define EMC_WDV0x5c +#define EMC_QUSE0x60 +#define EMC_QRST
Re: [PATCH v2 02/12] of: Document long-ram-code property in nvidia,tegra20-apbmisc
On 10/21/2014 05:45 PM, Tomeu Vizoso wrote: Needed to properly decode the ram code register. Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com --- Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt index b97b8be..e2562ed 100644 --- a/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt +++ b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt @@ -11,3 +11,6 @@ Required properties: The second entry gives the physical address and length of the registers indicating the strapping options. +Optional properties: +- nvidia,long-ram-code: boolean that tells whether the ram code is long (4 bit) + or short (2 bit). If not present, false. I think just If present, the RAM code is long (4 bit). If not, short (2 bit) would be clearer, as the booleanness of this property is not really present in the device tree file. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] of: Add Tegra124 EMC bindings
On 10/10/2014 04:14 PM, Mark Rutland wrote: On Fri, Oct 10, 2014 at 01:46:55PM +0100, Tomeu Vizoso wrote: From: Mikko Perttunen mperttu...@nvidia.com Add binding documentation for the nvidia,tegra124-emc device tree node. Signed-off-by: Mikko Perttunen mperttu...@nvidia.com Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com --- .../bindings/memory-controllers/tegra-emc.txt | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt diff --git a/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt b/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt new file mode 100644 index 000..6282c6b --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt @@ -0,0 +1,41 @@ +Tegra124 SoC EMC controller + +Required properties : +- compatible : nvidia,tegra124-emc. +- reg : Should contain 1 entry: + - EMC register set + +The node should contain a timings@i subnode for each supported RAM type + (see field RAM_CODE in register PMC_STRAPPING_OPT_A) +Required properties for timings@i nodes : +- nvidia,ram-code : Should contain the value of RAM_CODE this timing set + is used for. + +Each timings@i node should contain timing@j subnodes. One timing@j + node should exist for each supported EMC clock rate. What do the i and j correspond to? Arbitrary integers, preferably starting from 0 and increasing, similar as with regulator@i etc. Each set of `j's is independent. (Actually, these values are never used anywhere for anything). +Required properties for timing@j nodes : +- clock-frequency : Should contain the memory clock rate. +- nvidia,parent-clock-frequency : Should contain the rate of the EMC + clock's parent clock. Why are both of these properties necessary? What is the relationship between the two? There is a certain set of memory timings specified by the hardware manufacturer for each board type. Each memory timing contains the memory rate, parent clock and parent clock frequency and many other values which you mention later. +- 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: + - emc-parent : EMC's parent clock. Surely the clocks are a property of the EMC, and not the individual timings? The required parent for each timing is specified by the manufacturer. +- The following properties contain EMC timing characterization values: + - nvidia,emc-zcal-cnt-long + - nvidia,emc-auto-cal-interval + - nvidia,emc-ctt-term-ctrl + - nvidia,emc-cfg + - nvidia,emc-cfg-2 + - nvidia,emc-sel-dpd-ctrl + - nvidia,emc-cfg-dig-dll + - nvidia,emc-bgbias-ctl0 + - nvidia,emc-auto-cal-config + - nvidia,emc-auto-cal-config2 + - nvidia,emc-auto-cal-config3 + - nvidia,emc-mode-reset + - nvidia,emc-mode-1 + - nvidia,emc-mode-2 + - nvidia,emc-mode-4 +- nvidia,emc-configuration : EMC timing characterization data written to + EMC registers. I have no idea what any of these are. Perhaps these make sense, but I cannot tell. Magic values specified by the manufacturer. There is some sparse documentation in the Tegra TRM. TL;DR: The whole EMC sequence is rather magical and complicated so we stick to manufacturer-specified values rather than trying guess on our own. (Although this patch already calculates some stuff that's safe to calculate and that is manually specified by the downstream NVIDIA kernel.) Mark. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On 09/17/2014 01:40 AM, Stephen Warren wrote: That's a huge time-sink, unless I work out NFS root, which probably isn't properly or easily supported by any distro. FWIW, this is how I've been working, and it hasn't been /that/ difficult to get working. The Tegra side is trivial, just append something like ip=dhcp root=/dev/nfs nfsroot=host_ip:/your/nfsroot,v3,rsize=8192,wsize=8192,timeo=15 (Granted, I had to do a bit of mucking around before finding this working incantation..) to the kernel boot arguments. I've used Ubuntu 12.04, 13.10 and Arch Linux on my Jetson in this way. The more annoying part is the nfs host machine, but there are guides for that. Anyway, I've had both Ubuntu 12.04 and Arch working as hosts without problems. Mikko -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/9] pinctrl: tegra-xusb: Add USB PHY support
On 25/08/14 22:22, Stephen Warren wrote:
On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
In addition to the PCIe and SATA PHYs, the XUSB pad controller also
supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single
PCIe or SATA lane and is mapped to one of the three UTMI ports.
The xHCI controller will also send messages intended for the PHY driver,
so request and listen for messages on the mailbox's PHY channel.
I'd like a review from Thierry here as the HW expert.
I need an ack from LinusW in order to take this pinctrl patch through
the Tegra tree.
diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c
b/drivers/pinctrl/pinctrl-tegra-xusb.c
+static int usb3_phy_power_on(struct phy *phy)
+{
+struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
+int port = usb3_phy_to_port(phy);
+int lane = padctl-usb3_ports[port].lane;
+u32 value, offset;
+
+if (!is_pcie_or_sata_lane(lane)) {
+dev_err(padctl-dev, USB3 PHY %d mapped to invalid lane: %d\n,
+port, lane);
+return -EINVAL;
+}
An aside: This implies that the SATA driver should be talking to this
pinctrl driver and explicitly powering on the XUSB pins. However, the
SATA driver doesn't depend on this series. I'm a bit confused how that
works. Perhaps it's just by accident? Mikko, can you comment?
The SATA driver does depend on the pinctrl-tegra-xusb driver to power on
the SATA lane. It looks like what this patch does is it adds support for
using the SATA pad for USB3, in which case the SATA lane also needs to
be powered on. At least that's the understanding I got from a quick read.
Mikko
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/13] ARM: tegra: Enable the DFLL on the Jetson TK1
It might look nicer if the voltage table was in a separate file. A bit of a border case, maybe. On 11/07/14 00:42, Tuomas Tynkkynen wrote: ... + nvidia,pmic-voltage-table = + 0x1e 70, + 0x1f 71, + 0x20 72, + 0x21 73, + 0x22 74, + 0x23 75, + 0x24 76, + 0x25 77, + 0x26 78, + 0x27 79, + 0x28 80, + 0x29 81, + 0x2a 82, + 0x2b 83, + 0x2c 84, + 0x2d 85, + 0x2e 86, + 0x2f 87, + 0x30 88, + 0x31 89, + 0x32 90, + 0x33 91, + 0x34 92, + 0x35 93, + 0x36 94, + 0x37 95, + 0x38 96, + 0x39 97, + 0x3a 98, + 0x3b 99, + 0x3c 100, + 0x3d 101, + 0x3e 102, + 0x3f 103, + 0x40 104, + 0x41 105, + 0x42 106, + 0x43 107, + 0x44 108, + 0x45 109, + 0x46 110, + 0x47 111, + 0x48 112, + 0x49 113, + 0x4a 114, + 0x4b 115, + 0x4c 116, + 0x4d 117, + 0x4e 118, + 0x4f 119, + 0x50 120, + 0x51 121, + 0x52 122, + 0x53 123, + 0x54 124, + 0x55 125, + 0x56 126, + 0x57 127, + 0x58 128, + 0x59 129, + 0x5a 130, + 0x5b 131, + 0x5c 132, + 0x5d 133, + 0x5e 134, + 0x5f 135, + 0x60 136, + 0x61 137, + 0x62 138, + 0x63 139, + 0x64 140; ... -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/5] ARM: tegra: Add thermal reset (thermtrip) support to PMC
This adds a device tree controlled option to enable PMC-based
thermal reset in overheating situations. Thermtrip is supported on
Tegra114 and Tegra124. The thermal reset only works when the thermal
sensors are calibrated, so a soctherm driver is also required.
Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
---
arch/arm/mach-tegra/pmc.c | 95 +--
1 file changed, 91 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index e1677c0..69143cd 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -51,6 +51,22 @@
#define PMC_CPUPWRGOOD_TIMER 0xc8
#define PMC_CPUPWROFF_TIMER0xcc
+#define PMC_SENSOR_CTRL0x1b0
+#define PMC_SENSOR_CTRL_SCRATCH_WRITE (1 2)
+#define PMC_SENSOR_CTRL_ENABLE_RST (1 1)
+
+#define PMC_SCRATCH54 0x258
+#define PMC_SCRATCH54_DATA_SHIFT 8
+#define PMC_SCRATCH54_ADDR_SHIFT 0
+
+#define PMC_SCRATCH55 0x25c
+#define PMC_SCRATCH55_RESET_TEGRA (1 31)
+#define PMC_SCRATCH55_CNTRL_ID_SHIFT 27
+#define PMC_SCRATCH55_PINMUX_SHIFT 24
+#define PMC_SCRATCH55_16BITOP (1 15)
+#define PMC_SCRATCH55_CHECKSUM_SHIFT 16
+#define PMC_SCRATCH55_I2CSLV1_SHIFT0
+
static u8 tegra_cpu_domains[] = {
0xFF, /* not available for CPU0 */
TEGRA_POWERGATE_CPU1,
@@ -295,11 +311,19 @@ void tegra_pmc_suspend_init(void)
}
#endif
+#define PMC_HAS_THERMAL_RESET (1 0)
+
static const struct of_device_id matches[] __initconst = {
- { .compatible = nvidia,tegra124-pmc },
- { .compatible = nvidia,tegra114-pmc },
- { .compatible = nvidia,tegra30-pmc },
- { .compatible = nvidia,tegra20-pmc },
+ {
+ .compatible = nvidia,tegra124-pmc,
+ .data = (void *)PMC_HAS_THERMAL_RESET
+ },
+ {
+ .compatible = nvidia,tegra114-pmc,
+ .data = (void *)PMC_HAS_THERMAL_RESET
+ },
+ { .compatible = nvidia,tegra30-pmc, .data = 0 },
+ { .compatible = nvidia,tegra20-pmc, .data = 0 },
{ }
};
@@ -324,6 +348,67 @@ void __init tegra_pmc_init_irq(void)
tegra_pmc_writel(val, PMC_CTRL);
}
+void __init tegra_pmc_init_thermal_reset(struct device_node *np)
+{
+ u32 pmu_i2c_addr, i2c_ctrl_id, reg_addr, reg_data, pinmux;
+ bool pmu_16bit_ops;
+ u32 val, checksum;
+ const struct of_device_id *match = of_match_node(matches, np);
+
+ if (!((u32)match-data PMC_HAS_THERMAL_RESET))
+ return;
+
+ pmu_16bit_ops =
+ of_property_read_bool(np, nvidia,thermtrip-pmu-16bit-ops);
+ if (of_property_read_u32(
+ np, nvidia,thermtrip-pmu-i2c-addr, pmu_i2c_addr))
+ goto disabled;
+ if (of_property_read_u32(
+ np, nvidia,thermtrip-i2c-controller, i2c_ctrl_id))
+ goto disabled;
+ if (of_property_read_u32(
+ np, nvidia,thermtrip-reg-addr, reg_addr))
+ goto disabled;
+ if (of_property_read_u32(
+ np, nvidia,thermtrip-reg-data, reg_data))
+ goto disabled;
+ if (of_property_read_u32(
+ np, nvidia,thermtrip-pinmux, pinmux))
+ pinmux = 0;
+
+ val = tegra_pmc_readl(PMC_SENSOR_CTRL);
+ val |= PMC_SENSOR_CTRL_SCRATCH_WRITE | PMC_SENSOR_CTRL_ENABLE_RST;
+ tegra_pmc_writel(val, PMC_SENSOR_CTRL);
+
+ val = (reg_data PMC_SCRATCH54_DATA_SHIFT) |
+ (reg_addr PMC_SCRATCH54_ADDR_SHIFT);
+ tegra_pmc_writel(val, PMC_SCRATCH54);
+
+ val = 0;
+ val |= PMC_SCRATCH55_RESET_TEGRA;
+ val |= i2c_ctrl_id PMC_SCRATCH55_CNTRL_ID_SHIFT;
+ val |= pinmux PMC_SCRATCH55_PINMUX_SHIFT;
+ if (pmu_16bit_ops)
+ val |= PMC_SCRATCH55_16BITOP;
+ val |= pmu_i2c_addr PMC_SCRATCH55_I2CSLV1_SHIFT;
+
+ checksum = reg_addr + reg_data + (val 0xFF) + ((val 8) 0xFF) +
+ ((val 24) 0xFF);
+ checksum = 0xFF;
+ checksum = 0x100 - checksum;
+
+ val |= checksum PMC_SCRATCH55_CHECKSUM_SHIFT;
+
+ tegra_pmc_writel(val, PMC_SCRATCH55);
+
+ pr_info(Tegra: PMC thermal reset enabled\n);
+
+ return;
+
+disabled:
+ pr_warn(Tegra: PMC thermal reset disabled\n);
+}
+
void __init tegra_pmc_init(void)
{
struct device_node *np;
@@ -399,4 +484,6 @@ void __init tegra_pmc_init(void)
pmc_pm_data.lp0_vec_size = lp0_vec[1];
pmc_pm_data.suspend_mode = suspend_mode;
+
+ tegra_pmc_init_thermal_reset(np);
}
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/5] clk: tegra: Add soctherm and tsensor clocks to T124 initialization table
This adds the two clocks, soctherm and tsensor, to the T124 initialization
table.
They are required for soctherm-based thermal sensing.
Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
---
drivers/clk/tegra/clk-tegra124.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
index 80efe51..abeec63 100644
--- a/drivers/clk/tegra/clk-tegra124.c
+++ b/drivers/clk/tegra/clk-tegra124.c
@@ -1369,6 +1369,8 @@ static struct tegra_clk_init_table init_table[]
__initdata = {
{TEGRA124_CLK_XUSB_HS_SRC, TEGRA124_CLK_PLL_U_60M, 6000, 0},
{TEGRA124_CLK_XUSB_FALCON_SRC, TEGRA124_CLK_PLL_RE_OUT, 22400, 0},
{TEGRA124_CLK_XUSB_HOST_SRC, TEGRA124_CLK_PLL_RE_OUT, 11200, 0},
+ {TEGRA124_CLK_SOC_THERM, TEGRA124_CLK_PLL_P, 5100, 0},
+ {TEGRA124_CLK_TSENSOR, TEGRA124_CLK_CLK_M, 40, 0},
/* This MUST be the last entry. */
{TEGRA124_CLK_CLK_MAX, TEGRA124_CLK_CLK_MAX, 0, 0},
};
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 5/5] thermal: Add Tegra SOCTHERM thermal management driver
This adds support for the Tegra SOCTHERM thermal sensing and management
system found in the Tegra124 system-on-chip. Only polling-based thermal
sensing and overheating reset are supported for now.
Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
---
drivers/thermal/Kconfig | 6 +
drivers/thermal/Makefile | 1 +
drivers/thermal/tegra_soctherm.c | 502 +++
3 files changed, 509 insertions(+)
create mode 100644 drivers/thermal/tegra_soctherm.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index f9a1386..70835af 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -175,6 +175,12 @@ config ARMADA_THERMAL
Enable this option if you want to have support for thermal management
controller present in Armada 370 and Armada XP SoC.
+config TEGRA_SOCTHERM
+ tristate Tegra SOCTHERM thermal management
+ depends on ARCH_TEGRA
+ help
+ Enable this option for thermal management support on Tegra124 SoCs.
+
config DB8500_CPUFREQ_COOLING
tristate DB8500 cpufreq cooling
depends on ARCH_U8500
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index de0636a..d5d964b 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_X86_PKG_TEMP_THERMAL)+=
x86_pkg_temp_thermal.o
obj-$(CONFIG_INTEL_SOC_DTS_THERMAL)+= intel_soc_dts_thermal.o
obj-$(CONFIG_TI_SOC_THERMAL) += ti-soc-thermal/
obj-$(CONFIG_ACPI_INT3403_THERMAL) += int3403_thermal.o
+obj-$(CONFIG_TEGRA_SOCTHERM) += tegra_soctherm.o
diff --git a/drivers/thermal/tegra_soctherm.c b/drivers/thermal/tegra_soctherm.c
new file mode 100644
index 000..e1352f1
--- /dev/null
+++ b/drivers/thermal/tegra_soctherm.c
@@ -0,0 +1,502 @@
+/*
+ * drivers/thermal/tegra_soctherm.c
+ *
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Author:
+ * Mikko Perttunen mperttu...@nvidia.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/reset.h
+#include linux/thermal.h
+#include linux/tegra-soc.h
+
+#define SENSOR_CONFIG0 0
+#defineSENSOR_CONFIG0_STOP BIT(0)
+#defineSENSOR_CONFIG0_TALL_SHIFT 8
+#defineSENSOR_CONFIG0_TCALC_OVER BIT(4)
+#defineSENSOR_CONFIG0_OVER BIT(3)
+#defineSENSOR_CONFIG0_CPTR_OVERBIT(2)
+#define SENSOR_CONFIG1 4
+#defineSENSOR_CONFIG1_TSAMPLE_SHIFT0
+#defineSENSOR_CONFIG1_TIDDQ_EN_SHIFT 15
+#defineSENSOR_CONFIG1_TEN_COUNT_SHIFT 24
+#defineSENSOR_CONFIG1_TEMP_ENABLE BIT(31)
+#define SENSOR_CONFIG2 8
+#defineSENSOR_CONFIG2_THERMA_SHIFT 16
+#defineSENSOR_CONFIG2_THERMB_SHIFT 0
+
+#define THERMTRIP_CTL 0x80
+#defineTHERMTRIP_CTL_ANY_ENBIT(28)
+#defineTHERMTRIP_CTL_TSENSE_MASK 0xff
+#defineTHERMTRIP_CTL_TSENSE_SHIFT 0
+#defineTHERMTRIP_CTL_CPU_MASK 0xff00
+#defineTHERMTRIP_CTL_CPU_SHIFT 8
+#defineTHERMTRIP_CTL_GPU_MEM_MASK 0xff
+#defineTHERMTRIP_CTL_GPU_MEM_SHIFT 16
+#define THERMTRIP_DEFAULT_THRESHOLD105
+
+#define SENSOR_PDIV0x1c0
+#defineSENSOR_PDIV_T1240x
+#define SENSOR_HOTSPOT_OFF 0x1c4
+#defineSENSOR_HOTSPOT_OFF_T124 0x00060600
+#define SENSOR_TEMP1 0x1c8
+#defineSENSOR_TEMP1_CPU_TEMP_SHIFT 16
+#defineSENSOR_TEMP1_GPU_TEMP_MASK 0x
+#define SENSOR_TEMP2 0x1cc
+#defineSENSOR_TEMP2_MEM_TEMP_SHIFT 16
+#defineSENSOR_TEMP2_PLLX_TEMP_MASK 0x
+
+#define FUSE_TSENSOR8_CALIB0x180
+#define FUSE_SPARE_REALIGNMENT_REG_0 0x1fc
+
+#define NOMINAL_CALIB_FT_T124 105
+
+struct tegra_tsensor_configuration {
+ u32 tall, tsample, tiddq_en, ten_count;
+ u32 pdiv, tsample_ate, pdiv_ate;
+};
+
+struct tegra_tsensor {
+ const char *name;
+ u32
[RFC 1/5] ARM: tegra: Add PMC thermtrip programming to Jetson TK1 device tree
This adds the required information to reset the board during an overheating situation to the Jetson TK1 device tree. The thermal reset is handled by the PMC by sending an I2C message to the PMIC. The entries specify the I2C message to be sent. Signed-off-by: Mikko Perttunen mperttu...@nvidia.com --- arch/arm/boot/dts/tegra124-jetson-tk1.dts | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts index 16082c0..896c24b 100644 --- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts +++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts @@ -1617,6 +1617,11 @@ nvidia,core-pwr-off-time = 61036; nvidia,core-power-req-active-high; nvidia,sys-clock-req-active-high; + + nvidia,thermtrip-pmu-i2c-addr = 0x40; + nvidia,thermtrip-i2c-controller = 4; + nvidia,thermtrip-reg-addr = 0x36; + nvidia,thermtrip-reg-data = 0x2; }; /* SD card */ -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/5] Tegra124 thermal management
Hi, this patchset implements basic polled thermal sensing support and hardware initiated shutdown (thermtrip) in an overheating situations for the Tegra124 system-on-chip. The driver uses the of-thermal framework to expose the sensors to the thermal subsystem, and this works well for the simplest case of polled sensors. However, there are two features I'd like to implement that as far as I know the framework isn't really ready for: - hardware based trip points, i.e., interrupts at a configured temperature - hardware initiated cooling Thermtrip is an example of the latter, but the hardware is also capable of less drastic measures. Currently, the driver doesn't attempt to expose thermtrip using the framework, instead opting to use custom device tree properties, but this is something I'd like to move away from. To implement hardware based trip points, the sensor - of-thermal interface would need a new function, which the of-thermal framework would use to tell the driver of a new trip point. I suppose the best way to do this would be to have of-thermal manage trip points, and when one is reached, tell the driver to prepare for the next one. The sensor driver should be capable of managing two trip points, and below and one above the current temperature. Hardware initiated cooling is a bit more interesting. The hardware that initiates the cooling procedure necessarily has some view of the thermal sensors / thermal zones, so the thermal zones defined in the device tree should map exactly to those ones. Hardware based cooling devices should be defined in the device tree just like any other cooling devices. The problematic part is binding a trip point to a hardware cooling device. There would need some additional interface to tell the cooling device the temperature of the trip point it is bound to. Hardware cooling devices can also track multiple thermal zones (for example, thermtrip can trigger based on cpu, gpu, memory and tsense sensors). To distinguish between these in the device tree, I can think of two options: 1. Implement each tracked zone as a separate cooling device. (Probably by having an additional cooling-cell) This would make the interface simpler but allow impossible cooling mappings to be made in the device tree. 2. When telling the cooling device of a particular trip point, also tell it which thermal zone it is related to. This would require the cooling device to have some kind of ability to detect that a thermal zone object is a specific thermal zone. One more question related to hardware-initiated reset in an overheating situation: the critical trip level is designed to initiate a controller shutdown. Should there be a new trip level for an uncontrolled shutdown? Any thoughts would be appreciated. Thanks, Mikko Perttunen Mikko Perttunen (5): ARM: tegra: Add PMC thermtrip programming to Jetson TK1 device tree ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree ARM: tegra: Add thermal reset (thermtrip) support to PMC clk: tegra: Add soctherm and tsensor clocks to T124 initialization table thermal: Add Tegra SOCTHERM thermal management driver arch/arm/boot/dts/tegra124-jetson-tk1.dts | 5 + arch/arm/boot/dts/tegra124.dtsi | 47 +++ arch/arm/mach-tegra/pmc.c | 95 +- drivers/clk/tegra/clk-tegra124.c | 2 + drivers/thermal/Kconfig | 6 + drivers/thermal/Makefile | 1 + drivers/thermal/tegra_soctherm.c | 502 ++ 7 files changed, 654 insertions(+), 4 deletions(-) create mode 100644 drivers/thermal/tegra_soctherm.c -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/4] pinctrl: Add NVIDIA Tegra XUSB pad controller support
On 17/06/14 15:07, Thierry Reding wrote:
+static int tegra_xusb_padctl_pinconf_group_get(struct pinctrl_dev *pinctrl,
+ unsigned int group,
+ unsigned long *config)
+{
+ struct tegra_xusb_padctl *padctl = pinctrl_dev_get_drvdata(pinctrl);
+ const struct tegra_xusb_padctl_lane *lane;
+ enum tegra_xusb_padctl_param param;
+ u32 value;
+
+ param = TEGRA_XUSB_PADCTL_UNPACK_PARAM(*config);
+ lane = padctl-soc-lanes[group];
+
+ switch (param) {
+ case TEGRA_XUSB_PADCTL_IDDQ:
+ value = padctl_readl(padctl, lane-offset);
+ value = (value lane-iddq) 0x1;
+ *config = TEGRA_XUSB_PADCTL_PACK(param, value);
+ break;
+
+ default:
+ dev_err(padctl-dev, invalid configuration parameter: %04x\n,
+ param);
+ return -ENOTSUPP;
+ }
+
+ return 0;
+}
I guess `value' should also be negated here?
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/4] of: Add NVIDIA Tegra XUSB pad controller binding
On 17/06/14 19:24, Stephen Warren wrote: On 06/17/2014 06:07 AM, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com This patch adds the device tree binding documentation for the XUSB pad controller found on NVIDIA Tegra SoCs. It exposes both pinmuxing and PHY capabilities. Thanks. I'll wait for a Tested-by from Mikko and an Acked-by from Linus before taking this series. With or without negation added to group_get (see reply to 2/4), the series: Tested-by: Mikko Perttunen mperttu...@nvidia.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] pinctrl: Add NVIDIA Tegra XUSB pad controller support
This v3 breaks SATA; see below On 16/06/14 17:57, Thierry Reding wrote: ... + regval = padctl_readl(padctl, lane-offset); + + if (!value) + regval = ~lane-iddq; + else + regval |= lane-iddq; + + padctl_writel(padctl, regval, lane-offset); ... The bits at at lane-iddq are actually IDDQ_DISABLE bits, so this is the wrong way around: having iddq = 0 in device tree leads to the device turning off. So either the DT property should be renamed or the branches of the if here should be switched around. v2 used the wrong variable so the else branch ended up being chosen each time, this also meant that SATA worked by chance. - Mikko -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver
On 06/17/2014 07:15 PM, Stephen Warren wrote: On 06/17/2014 06:16 AM, Tomeu Vizoso wrote: On 06/16/2014 10:02 PM, Stephen Warren wrote: On 06/16/2014 07:35 AM, Tomeu Vizoso wrote: This binding looks quite anaemic vs. Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt; I would expect that this binding needs all the EMC register data from the tegra20-emc binding too. Can the two bindings be identical? There's even less stuff needed right now, as all what ultimately the EMC driver does is call clk_set_rate on the EMC clock. As the T124 EMC driver gains more features, they should get more similar. IIRC, even changing the EMC clock rate requires modifying the memory controller's programming (e.g. delays/taps/tuning etc.). That's exactly what the more complex stuff in the nvidia,tegra20-emc.txt is all about. I not convinced that a driver that just modifies the clock rate without adjusting the EMC programming will work reliably. Indeed, changing the EMC clock rate is a somewhat complicated sequence of ~10 steps. The kernel even won't let one the rate be change directly, as the change would be propagated to PLL_M which cannot have its rate changed while it is enabled. I suppose the sequence should be hidden in the EMC clk's set_rate implementation, which I guess would leave just the rate policy to this driver. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver
It should be mentioned that calling clk_set_rate on the EMC clock
currently does absolutely nothing (except probably returning an error).
The rate switching sequence is not implemented (nor is the clock tree
entirely correct. For example, the kernel thinks that PLL_M is disabled).
Another note: I am currently implementing an actmon driver. I'm not
entirely enthusiastic about the downstream style of managing EMC rate
policy in the actmon driver, but haven't yet given much thought to it.
Yet another note: I think the exported API should not be SoC-specific,
so s/tegra124_/tegra_/.
Thanks,
- Mikko
On 06/16/2014 04:35 PM, Tomeu Vizoso wrote:
Adds functionality for registering memory bandwidth needs and setting
the EMC clock rate based on that.
Also adds API for setting floor and ceiling frequency rates.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
.../bindings/arm/tegra/nvidia,tegra124-emc.txt | 26
drivers/memory/Kconfig | 8 +
drivers/memory/Makefile| 1 +
drivers/memory/tegra124-emc.c | 173 +
include/linux/platform_data/tegra_emc.h| 23 +++
5 files changed, 231 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra124-emc.txt
create mode 100644 drivers/memory/tegra124-emc.c
diff --git
a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra124-emc.txt
b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra124-emc.txt
new file mode 100644
index 000..88e6a55
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra124-emc.txt
@@ -0,0 +1,26 @@
+Tegra124 External Memory Controller
+
+Properties:
+- compatible : Should contain nvidia,tegra124-emc.
+- reg : Should contain the register range of the device
+- #address-cells : Should be 1
+- #size-cells : Should be 0
+- nvidia,mc : phandle to the mc bus connected to EMC.
+- clocks : phandle to EMC, EMC shared bus override, and all parent clocks.
+- clock-names : name of each clock.
+- nvidia,pmc : phandle to the PMC syscon node.
+- max-clock-frequency : optional, specifies the maximum EMC rate in kHz.
+
+Child device nodes describe the memory settings for different configurations
and
+clock rates.
+
+Example:
+
+ memory-controller@7001b000 {
+ compatible = nvidia,tegra124-emc;
+ reg = 0x7001b000 0x1000;
+ #address-cells = 1;
+ #size-cells = 0;
+ clocks = tegra_car TEGRA124_CLK_EMC;
+ clock-names = emc;
+ };
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index c59e9c9..48fa0dd 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -61,6 +61,14 @@ config TEGRA30_MC
analysis, especially for IOMMU/SMMU(System Memory Management
Unit) module.
+config TEGRA124_EMC
+ tristate Tegra124 External Memory Controller (EMC) driver
+ default y
+ depends on ARCH_TEGRA_124_SOC
+ help
+ This driver is for the External Memory Controller (EMC) module
+ available in Tegra124 SoCs.
+
config FSL_IFC
bool
depends on FSL_SOC
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 71160a2..0b7290b 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
obj-$(CONFIG_MVEBU_DEVBUS)+= mvebu-devbus.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
+obj-$(CONFIG_TEGRA124_EMC) += tegra124-emc.o
diff --git a/drivers/memory/tegra124-emc.c b/drivers/memory/tegra124-emc.c
new file mode 100644
index 000..b7a54a5
--- /dev/null
+++ b/drivers/memory/tegra124-emc.c
@@ -0,0 +1,173 @@
+/*
+ * Copyright (c) 2013, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/of_platform.h
+#include linux/platform_data/tegra_emc.h
+
+#define DRV_NAME tegra124-emc
+#define EMC_FREQ_CUTOFF_USE_130_PERCENT1
+#define EMC_FREQ_CUTOFF_USE_140_PERCENT5000
+#define BYTES_PER_EMC_CLOCK 16
+
+struct tegra124_emc {
+ struct clk *clk;
+ unsigned long bandwidth_requests[TEGRA_EMC_CONSUMER_LAST];
+ unsigned long floor_freq;
+ unsigned
Re: [RFC PATCH 4/4] cpufreq: tegra: Register a minimum EMC frequency based on the CPU clock
The tegra-cpufreq driver is only for Tegra20, an upcoming driver for
Tegra124 will be separate, so this is not needed.
Thanks,
- Mikko
On 06/16/2014 04:35 PM, Tomeu Vizoso wrote:
Instead of setting a direct correlation to the CPU frequency. This allows
for other devices to influence the final effective EMC frequency.
In the future, this should be done instead by an ACTMON driver,
which would also take load stats into account when calculating the
floor EMC frequency.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
drivers/cpufreq/tegra-cpufreq.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c
index 8084c7f..64935f8 100644
--- a/drivers/cpufreq/tegra-cpufreq.c
+++ b/drivers/cpufreq/tegra-cpufreq.c
@@ -26,6 +26,7 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
+#include linux/platform_data/tegra_emc.h
static struct cpufreq_frequency_table freq_table[] = {
{ .frequency = 216000 },
@@ -44,7 +45,6 @@ static struct cpufreq_frequency_table freq_table[] = {
static struct clk *cpu_clk;
static struct clk *pll_x_clk;
static struct clk *pll_p_clk;
-static struct clk *emc_clk;
static bool pll_x_prepared;
static unsigned int tegra_get_intermediate(struct cpufreq_policy *policy,
@@ -96,15 +96,15 @@ static int tegra_target(struct cpufreq_policy *policy,
unsigned int index)
int ret = 0;
/*
-* Vote on memory bus frequency based on cpu frequency
+* Set minimum memory bus frequency based on cpu frequency
* This sets the minimum frequency, display or avp may request higher
*/
if (rate = 816000)
- clk_set_rate(emc_clk, 6); /* cpu 816 MHz, emc max */
+ tegra124_emc_set_floor(6); /* cpu 816 MHz, emc max */
else if (rate = 456000)
- clk_set_rate(emc_clk, 3); /* cpu 456 MHz, emc 150Mhz */
+ tegra124_emc_set_floor(3); /* cpu 456 MHz, emc 150Mhz */
else
- clk_set_rate(emc_clk, 1); /* emc 50Mhz */
+ tegra124_emc_set_floor(1); /* emc 50Mhz */
/*
* target freq == pll_p, don't need to take extra reference to pll_x_clk
@@ -141,14 +141,12 @@ static int tegra_cpu_init(struct cpufreq_policy *policy)
if (policy-cpu = NUM_CPUS)
return -EINVAL;
- clk_prepare_enable(emc_clk);
clk_prepare_enable(cpu_clk);
/* FIXME: what's the actual transition time? */
ret = cpufreq_generic_init(policy, freq_table, 300 * 1000);
if (ret) {
clk_disable_unprepare(cpu_clk);
- clk_disable_unprepare(emc_clk);
return ret;
}
@@ -160,7 +158,6 @@ static int tegra_cpu_init(struct cpufreq_policy *policy)
static int tegra_cpu_exit(struct cpufreq_policy *policy)
{
clk_disable_unprepare(cpu_clk);
- clk_disable_unprepare(emc_clk);
return 0;
}
@@ -194,19 +191,12 @@ static int __init tegra_cpufreq_init(void)
if (IS_ERR(pll_p_clk))
return PTR_ERR(pll_p_clk);
- emc_clk = clk_get_sys(cpu, emc);
- if (IS_ERR(emc_clk)) {
- clk_put(cpu_clk);
- return PTR_ERR(emc_clk);
- }
-
return cpufreq_register_driver(tegra_cpufreq_driver);
}
static void __exit tegra_cpufreq_exit(void)
{
cpufreq_unregister_driver(tegra_cpufreq_driver);
- clk_put(emc_clk);
clk_put(cpu_clk);
}
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] ARM: tegra: Add SATA controller to Tegra124 device tree
This adds the integrated AHCI-compliant Serial ATA controller present
in Tegra124 systems-on-chip to the Tegra124 device tree.
Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
Cc: devicetree@vger.kernel.org
---
arch/arm/boot/dts/tegra124.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 90f11ea..e647f30 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -787,6 +787,30 @@
status = disabled;
};
+ sata@0,7002 {
+ compatible = nvidia,tegra124-ahci;
+
+ reg = 0x0 0x70027000 0x0 0x2000, /* AHCI */
+ 0x0 0x7002 0x0 0x7000; /* SATA */
+
+ interrupts = 0 23 IRQ_TYPE_LEVEL_HIGH;
+
+ clocks = tegra_car TEGRA124_CLK_SATA,
+ tegra_car TEGRA124_CLK_SATA_OOB,
+ tegra_car TEGRA124_CLK_CML1,
+ tegra_car TEGRA124_CLK_PLL_E;
+
+ resets = tegra_car 124,
+ tegra_car 123,
+ tegra_car 129;
+ reset-names = sata, sata-oob, sata-cold;
+
+ phys = padctl TEGRA_XUSB_PADCTL_SATA;
+ phy-names = sata-phy;
+
+ status = disabled;
+ };
+
cpus {
#address-cells = 1;
#size-cells = 0;
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] ARM: tegra: Add SATA and SATA power to Jetson TK1 device tree
This enables the integrated SATA controller on the Tegra124 system-on-chip
on the Jetson TK1 board and adds regulators for the onboard Molex connector
commonly used to power SATA devices. The regulators are marked always-on
since they can be used for other purposes than powering SATA devices.
Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
Cc: devicetree@vger.kernel.org
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 38d3087..33a062c 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1686,6 +1686,17 @@
vbus-supply = vdd_usb3_vbus;
};
+ /* Serial ATA */
+ sata@0,7002 {
+ status = okay;
+
+ hvdd-supply = vdd_3v3_lp0;
+ vddio-supply = vdd_1v05_run;
+ avdd-supply = vdd_1v05_run;
+
+ target-supply = vdd_5v0_sata;
+ };
+
clocks {
compatible = simple-bus;
#address-cells = 1;
@@ -1827,6 +1838,31 @@
enable-active-high;
vin-supply = vdd_5v0_sys;
};
+
+ /* Molex power connector */
+ vdd_5v0_sata: regulator@13 {
+ compatible = regulator-fixed;
+ reg = 13;
+ regulator-name = +5V_SATA;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpio TEGRA_GPIO(EE, 2) GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ vin-supply = vdd_5v0_sys;
+ regulator-always-on;
+ };
+
+ vdd_12v0_sata: regulator@14 {
+ compatible = regulator-fixed;
+ reg = 14;
+ regulator-name = +12V_SATA;
+ regulator-min-microvolt = 1200;
+ regulator-max-microvolt = 1200;
+ gpio = gpio TEGRA_GPIO(EE, 2) GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ vin-supply = vdd_mux;
+ regulator-always-on;
+ };
};
sound {
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] of: Add NVIDIA Tegra SATA controller binding
This patch adds device tree binding documentation for the SATA controller found on NVIDIA Tegra SoCs. Signed-off-by: Mikko Perttunen mperttu...@nvidia.com Cc: devicetree@vger.kernel.org --- .../devicetree/bindings/ata/tegra-sata.txt | 29 ++ 1 file changed, 29 insertions(+) create mode 100644 Documentation/devicetree/bindings/ata/tegra-sata.txt diff --git a/Documentation/devicetree/bindings/ata/tegra-sata.txt b/Documentation/devicetree/bindings/ata/tegra-sata.txt new file mode 100644 index 000..70e3119 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/tegra-sata.txt @@ -0,0 +1,29 @@ +Tegra124 SoC SATA AHCI controller + +Required properties : + - compatible : Should be nvidia,tegra124-ahci. + - reg : Defines the following set of registers, in the order listed: + - AHCI register set (SATA BAR5) + - SATA register set + - interrupts : Defines the interrupt used by SATA + - clocks : Defines the clocks listed in the clock-names property. + - clock-names : The following clock names must be present: + - sata + - sata-oob + - cml1 + - pll_e + - resets : Defines the resets listed in the reset-names property + - reset-names : The following reset names must be present: + - sata + - sata-oob + - sata-cold + - phys : Defines the phys listed in the phy-names property + - phy-names : The following phy names must be present: + - sata-phy : XUSB PADCTL SATA PHY + - hvdd-supply : Defines the SATA HVDD regulator + - vddio-supply : Defines the SATA VDDIO regulator + - avdd-supply : Defines the SATA AVDD regulator + +Optional properties: + - target-supply : Defines a regulator for a power output connector + for SATA devices. -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
