From: Stephen Warren <hidden> Date: 2012-06-27 00:31:00
From: Stephen Warren <redacted>
The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this.
Three data sources were used for the data encoded here:
* The HW defaults, as extracted from real HW.
* The schematic, which specifies a voltage for each rail in the signal
names.
* The AC100 kernel used by the Ubuntu port:
repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git
branch chromeos-ac100-3.0
file arch/arm/mach-tegra/board-paz00-power.c
For many rails, the constraints in that tree specified differing min
and max voltages. In all cases, the min value was ignored, since
there's no need currently to vary any of the voltages at run-time.
DVFS might change this in the future.
In most cases these sources all matched. Differences are:
sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max
of 1.3v, but this wasn't applied since apply_uV wasn't set.
sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max
of 1.125v, but this wasn't applied since apply_uV wasn't set.
ldo0: The HW default is 1.2v. The schematic and marvin24's kernel state
this should be 3.3v. On similar board designs, this rail is typically
used for PCIe clock which requires 3.3v. Note that this rail isn't
actually used on this board.
ldo3: The HW default is on. marvin24's kernel didn't specify always-on,
but since the board wasn't marked as having fully constrained regulators,
the rail was not turned off, so the difference had no effect. The rail
is needed for USB.
Cc: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Stephen Warren <redacted>
---
v2:
* Made all constraints specify a single voltage rather than different
min/max, per description above.
* Removed vin-supply properties from LDO nodes; the driver and binding
need to be updated to support specifying the parent regulators before
we can put these into DT.
---
arch/arm/boot/dts/tegra20-paz00.dts | 130 +++++++++++++++++++++++++++++++++++
1 files changed, 130 insertions(+), 0 deletions(-)
From: Mark Brown <hidden> Date: 2012-06-27 11:31:01
On Tue, Jun 26, 2012 at 06:31:00PM -0600, Stephen Warren wrote:
sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max
of 1.125v, but this wasn't applied since apply_uV wasn't set.
apply_uV is only valid if a single voltage is specified. If a voltage
range were specified and it were acted on we'd take the lowest (not
highest) voltage allowed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120627/60890ab1/attachment.sig>
From: Stephen Warren <hidden> Date: 2012-06-27 17:08:14
On 06/27/2012 05:31 AM, Mark Brown wrote:
On Tue, Jun 26, 2012 at 06:31:00PM -0600, Stephen Warren wrote:
quoted
sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max
of 1.125v, but this wasn't applied since apply_uV wasn't set.
apply_uV is only valid if a single voltage is specified. If a voltage
range were specified and it were acted on we'd take the lowest (not
highest) voltage allowed.
Ah right. When I apply this, I'll reword that to something more like:
sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a
max of 1.125v, but this higher voltage was only applied to HW by DVFS
code, which isn't currently supported in mainline.
On Wednesday 27 June 2012 12:31:01 Mark Brown wrote:
On Tue, Jun 26, 2012 at 06:31:00PM -0600, Stephen Warren wrote:
quoted
sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max
of 1.125v, but this wasn't applied since apply_uV wasn't set.
apply_uV is only valid if a single voltage is specified.
yes, that's why there is a ".apply_uV = (_minmv == _maxmv)" in the regulator
macro.
If a voltage
range were specified and it were acted on we'd take the lowest (not
highest) voltage allowed.
Sorry, I don't get it. In this case, the board wouldn't boot at all because
nearly all supplies would be undervoltaged. I just checked and all voltages
are actually set to the *highest* (max) value. Maybe they aren't changed at
all?
Marc
From: Stephen Warren <hidden> Date: 2012-06-27 18:56:01
On 06/27/2012 12:50 PM, Marc Dietrich wrote:
On Wednesday 27 June 2012 12:31:01 Mark Brown wrote:
quoted
On Tue, Jun 26, 2012 at 06:31:00PM -0600, Stephen Warren wrote:
quoted
sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max
of 1.125v, but this wasn't applied since apply_uV wasn't set.
apply_uV is only valid if a single voltage is specified.
yes, that's why there is a ".apply_uV = (_minmv == _maxmv)" in the regulator
macro.
quoted
If a voltage
range were specified and it were acted on we'd take the lowest (not
highest) voltage allowed.
Sorry, I don't get it. In this case, the board wouldn't boot at all because
nearly all supplies would be undervoltaged. I just checked and all voltages
are actually set to the *highest* (max) value. Maybe they aren't changed at
all?
Yes, in the absence of any explicit action (i.e. a call to
regulator_set_voltage() elsewhere), the regulator core doesn't reprogram
the regulator at registration time, except for a few specific conditions
e.g. something like when min==max and apply_uV is set.
I imagine the DVFS code in your downstream kernel /is/ calling
regulator_set_voltage() later, assuming that config option is enabled
anyway. See arch/arm/mach-tegra/{dvfs.c,tegra2_dvfs.c}.
On Wednesday 27 June 2012 12:56:01 Stephen Warren wrote:
On 06/27/2012 12:50 PM, Marc Dietrich wrote:
quoted
On Wednesday 27 June 2012 12:31:01 Mark Brown wrote:
quoted
On Tue, Jun 26, 2012 at 06:31:00PM -0600, Stephen Warren wrote:
quoted
sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a
max
of 1.125v, but this wasn't applied since apply_uV wasn't set.
apply_uV is only valid if a single voltage is specified.
yes, that's why there is a ".apply_uV = (_minmv == _maxmv)" in the
regulator macro.
quoted
If a voltage
range were specified and it were acted on we'd take the lowest (not
highest) voltage allowed.
Sorry, I don't get it. In this case, the board wouldn't boot at all
because
nearly all supplies would be undervoltaged. I just checked and all
voltages
are actually set to the *highest* (max) value. Maybe they aren't changed
at
all?
Yes, in the absence of any explicit action (i.e. a call to
regulator_set_voltage() elsewhere), the regulator core doesn't reprogram
the regulator at registration time, except for a few specific conditions
e.g. something like when min==max and apply_uV is set.
I imagine the DVFS code in your downstream kernel /is/ calling
regulator_set_voltage() later, assuming that config option is enabled
anyway. See arch/arm/mach-tegra/{dvfs.c,tegra2_dvfs.c}.
Great, so all the tables (except sm0/1) were moot :-( At least I learned
something again ;-)
Stephen, I'm going to test your patch, just a few minutes ...
Thanks
Marc
On Tuesday 26 June 2012 18:31:00 Stephen Warren wrote:
From: Stephen Warren <redacted>
The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this.
[...]
Cc: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Stephen Warren <redacted>
I tested this on paz00 using linux-next and found no issues, so feel free to
add ...
Tested-By: Marc Dietrich <marvin24@gmx.de>
quoted hunk
---
v2:
* Made all constraints specify a single voltage rather than different
min/max, per description above.
* Removed vin-supply properties from LDO nodes; the driver and binding
need to be updated to support specifying the parent regulators before
we can put these into DT.
---
arch/arm/boot/dts/tegra20-paz00.dts | 130
+++++++++++++++++++++++++++++++++++ 1 files changed, 130 insertions(+), 0
deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts index 684a9e1..dccc8b4 100644