| Message ID | 1374442132-24040-5-git-send-email-dev@lynxeye.de |
|---|---|
| State | Superseded, archived |
| Headers | show |
On 07/21/2013 02:28 PM, Lucas Stach wrote: > Core and CPU voltage settings were a bit on the safe side. The actually > used chips on the Colibri allow for lower voltages and work just fine > this way. That sounds like a non-critical issue. Shouldn't that part be separated out into a patch for 3.12? > SM2 is not a the parent of LDO regs, but actually the DDR regulator. The > Colibri uses a different version of the TPS with other voltage mapping > tables for SM2, currently we cheat by setting a fake 3,2V which results > in 1,8V physical. That's quite unfortunate. Since DT is supposed to be an ABI, the existing DT should continue to work for arbitrary kernels, and the modified DT should also work for arbitrary kernels. Clearly that isn't possible if we start putting incorrect voltage values into the DT. Isn't there some way to make an isolated fix to the PMIC driver itself so that it actually programs the HW correctly? Even if that patch is larger than this patch, it still seems more likely to be acceptable for 3.11. But is this a regression? If not, how far back in CC: stable should this change go? -- 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
Am Dienstag, den 23.07.2013, 11:07 -0700 schrieb Stephen Warren: > On 07/21/2013 02:28 PM, Lucas Stach wrote: > > Core and CPU voltage settings were a bit on the safe side. The actually > > used chips on the Colibri allow for lower voltages and work just fine > > this way. > > That sounds like a non-critical issue. Shouldn't that part be separated > out into a patch for 3.12? Hm, yes. > > > SM2 is not a the parent of LDO regs, but actually the DDR regulator. The > > Colibri uses a different version of the TPS with other voltage mapping > > tables for SM2, currently we cheat by setting a fake 3,2V which results > > in 1,8V physical. > > That's quite unfortunate. Since DT is supposed to be an ABI, the > existing DT should continue to work for arbitrary kernels, and the > modified DT should also work for arbitrary kernels. Clearly that isn't > possible if we start putting incorrect voltage values into the DT. Isn't > there some way to make an isolated fix to the PMIC driver itself so that > it actually programs the HW correctly? Even if that patch is larger than > this patch, it still seems more likely to be acceptable for 3.11. > I'm a bit one the fence here. One the one hand it's a severe issue as the DDR ram gets overvolted by a fair bit and should be fixed by putting the correct voltage in the DT and getting this into stable. On the other hand this will prevent older kernels from working correctly as with 1,8V set on this rail the regulator driver will just plainly refuse to probe. Thinking again about this maybe it really the best thing to get the DT right first with CC stable and then changing the regulator driver and try and see if stable also accepts this patch. I don't really want to leave people with a supposedly working system, but constantly overvolting their RAM. > But is this a regression? If not, how far back in CC: stable should this > change go? This is not a regression. It was introduced with the original Colibri T20 commit and was caused by Toradex not providing any schematics for the Module plus me not physically checking this voltage rail before pushing things out. Regards, Lucas -- 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 07/23/2013 01:35 PM, Lucas Stach wrote: > Am Dienstag, den 23.07.2013, 11:07 -0700 schrieb Stephen Warren: >> On 07/21/2013 02:28 PM, Lucas Stach wrote: ... >>> SM2 is not a the parent of LDO regs, but actually the DDR regulator. The >>> Colibri uses a different version of the TPS with other voltage mapping >>> tables for SM2, currently we cheat by setting a fake 3,2V which results >>> in 1,8V physical. ... >> But is this a regression? If not, how far back in CC: stable should this >> change go? > > This is not a regression. It was introduced with the original Colibri > T20 commit and was caused by Toradex not providing any schematics for > the Module plus me not physically checking this voltage rail before > pushing things out. FYI, the reason I ask is that there's more push-back on adding patches late in the rc cycle (or after release, to -stable) for things that are not regressions. A safety issue like over-voltage might well still qualify to be accepted, but fixes for regressions are even more likely to be accepted. -- 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
Hi, I ran the mainline Kernel the first time on my Colibri T20. I compiled 3.11-rc2 without any patch, but the kernel refused to boot, the boot process freezed just while probing SM2: [ 0.420075] vdd_sm2,vdd_ddr: 3700 mV I then applied this patch, but without luck, the freeze happend even earlier: [ 0.413314] vdd_sm1,vdd_cpu: supplied by vdd_5v0 However, using 3.8 works for me: [ 0.419848] vdd_sm2,vdd_ddr: 3800 mV [ 0.423851] vdd_sm2,vdd_ddr: supplied by vdd_5v0 My Module Version is 1.2a with TPS658643 PMIC on it. Am 2013-07-21 23:28, schrieb Lucas Stach: > Core and CPU voltage settings were a bit on the safe side. The actually > used chips on the Colibri allow for lower voltages and work just fine > this way. This voltages seem to work for me too... > SM2 is not a the parent of LDO regs, but actually the DDR regulator. The > Colibri uses a different version of the TPS with other voltage mapping > tables for SM2, currently we cheat by setting a fake 3,2V which results > in 1,8V physical. I could successfully boot with 1.8V, but with messages complaining that probe failed... -- Stefan -- 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 Sun, Jul 21, 2013 at 11:28:52PM +0200, Lucas Stach wrote: > Core and CPU voltage settings were a bit on the safe side. The actually > used chips on the Colibri allow for lower voltages and work just fine > this way. > > SM2 is not a the parent of LDO regs, but actually the DDR regulator. The > Colibri uses a different version of the TPS with other voltage mapping > tables for SM2, currently we cheat by setting a fake 3,2V which results > in 1,8V physical. > > Signed-off-by: Lucas Stach <dev@lynxeye.de> > --- > The issue with the used version of the PMIC having a different voltage > mapping for SM2 should be resolved properly. As this needs some bigger > adjustments at the regulator driver this quick fix is just aimed at > stopping slight overvolting of the ram with 3.11 kernels. A proper fix > should land in time for 3.12. This wouldn't happen to be the TPS658640? I remember a similar problem with a special version of Tamonten that had this version of the PMU which supposedly is pin and register-compatible. Well, it is register compatible alright, and the pins are the same as well, but the voltage tables are slightly different. I did attempt to work the changes into the tps6586x driver at some point but there were a few things that made it much more difficult than I had imagined. Thierry
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi index 92551ba..9b56dcb 100644 --- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi +++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi @@ -226,14 +226,14 @@ gpio-controller; sys-supply = <&vdd_5v0_reg>; - vin-sm0-supply = <&sys_reg>; - vin-sm1-supply = <&sys_reg>; - vin-sm2-supply = <&sys_reg>; - vinldo01-supply = <&sm2_reg>; - vinldo23-supply = <&sm2_reg>; - vinldo4-supply = <&sm2_reg>; - vinldo678-supply = <&sm2_reg>; - vinldo9-supply = <&sm2_reg>; + vin-sm0-supply = <&vdd_5v0_reg>; + vin-sm1-supply = <&vdd_5v0_reg>; + vin-sm2-supply = <&vdd_5v0_reg>; + vinldo01-supply = <&vdd_5v0_reg>; + vinldo23-supply = <&vdd_5v0_reg>; + vinldo4-supply = <&vdd_5v0_reg>; + vinldo678-supply = <&vdd_5v0_reg>; + vinldo9-supply = <&vdd_5v0_reg>; regulators { #address-cells = <1>; @@ -250,8 +250,8 @@ reg = <1>; regulator-compatible = "sm0"; regulator-name = "vdd_sm0,vdd_core"; - regulator-min-microvolt = <1275000>; - regulator-max-microvolt = <1275000>; + regulator-min-microvolt = <1225000>; + regulator-max-microvolt = <1225000>; regulator-always-on; }; @@ -259,17 +259,20 @@ reg = <2>; regulator-compatible = "sm1"; regulator-name = "vdd_sm1,vdd_cpu"; - regulator-min-microvolt = <1100000>; - regulator-max-microvolt = <1100000>; + regulator-min-microvolt = <1025000>; + regulator-max-microvolt = <1025000>; regulator-always-on; }; sm2_reg: regulator@3 { reg = <3>; regulator-compatible = "sm2"; - regulator-name = "vdd_sm2,vin_ldo*"; - regulator-min-microvolt = <3700000>; - regulator-max-microvolt = <3700000>; + regulator-name = "vdd_sm2,vdd_ddr"; + /* The voltage is lying, but results + in the desired 1,8V on the TPS version + used on the Colibri */ + regulator-min-microvolt = <3200000>; + regulator-max-microvolt = <3200000>; regulator-always-on; };
Core and CPU voltage settings were a bit on the safe side. The actually used chips on the Colibri allow for lower voltages and work just fine this way. SM2 is not a the parent of LDO regs, but actually the DDR regulator. The Colibri uses a different version of the TPS with other voltage mapping tables for SM2, currently we cheat by setting a fake 3,2V which results in 1,8V physical. Signed-off-by: Lucas Stach <dev@lynxeye.de> --- The issue with the used version of the PMIC having a different voltage mapping for SM2 should be resolved properly. As this needs some bigger adjustments at the regulator driver this quick fix is just aimed at stopping slight overvolting of the ram with 3.11 kernels. A proper fix should land in time for 3.12. --- arch/arm/boot/dts/tegra20-colibri-512.dtsi | 33 ++++++++++++++++-------------- 1 file changed, 18 insertions(+), 15 deletions(-)