On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown <broonie@xxxxxxxxxx> wrote:
> On Thu, Aug 29, 2013 at 08:29:37AM -0700, Kevin Hilman wrote:
>> On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie@xxxxxxxxxx> wrote:
>
>> > Someone is going to have to walk me through the context for me to fully
>> > understand what this is all about - what's the problem?
>
>> The basic problem is how to have low-level platform code (or possibly
>> firmware) send commands to a regulator to scale voltage. This has to
>> happen *very* late in the suspend process, so having the drivers do it
>> themselves is not feasible.
>
> Why does it have to happen this late and are the sequences definitely
> fixed ones not ones that could depend on the system state at the time
> we suspend? It'd help to know what exactly is being controlled here...
On all am335x platforms, the lower operating point for core voltage
cannot be reached without first disabling the DDR controller, and
programming it into a lower power mode. For DDR3 platforms, no such
lower power mode is available and the lower operating point for core
voltage can only be reached with the memory controller disabled.
It certainly is possible that some bizarre I2C regulator may mix in
regulator voltage and some other state into one I2C register. In the
case of such a platform, setting the lower operating point would not
be supported.
>> The proposal in this series is to define the i2c commands sequence to
>> be sent to the regulator in the i2c node of the DT. The
>> platform-specific code then reads the sequence from the DT and sends
>> the commands (or in in the case of the current series, passes the
>> sequence to some firmware on a microcontroller which does the
>> sequence.)
>
> Surely specifying things in terms of the actual sequence would be better
> than trying to specify the I2C commands if you want this to be done from
> Linux? If the firmware has to cope directly then this would require the
> firmware to understand what it's doing of course.
I'm not sure what you mean by "actual sequence". Maybe if I show you a
couple examples, it will be more clear:
This is for the AM335X-EVM which has a TPS65910. The first byte is the
number of bytes to write, the second byte is the I2C device to write
those bytes to, the third byte happens to be a register address on the
TPS65910, and the 4th byte happens to be the value for 0.95V and 1.1V
respectively.
/* Set OPP50 (0.95V) for VDD core on TPS65910 */
sleep_sequence = /bits/ 8 <
0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */
>;
/* Set OPP100 (1.10V) for VDD core on TPS65910 */
wake_sequence = /bits/ 8 <
0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */
>;
These next sequences are for the Beaglebone which has a different
PMIC. The format is the same, but the PMIC requires an unlock sequence
to be performed for certain registers and it also requires an
additional step to apply DCDC changes:
/* Set OPP50 (0.95V) for VDD core on TPS65217 */
sleep_sequence = /bits/ 8 <
0x02 0x24 0x0b 0x6d /* Password unlock 1 */
0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */
0x02 0x24 0x0b 0x6d /* Password unlock 2 */
0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */
0x02 0x24 0x0b 0x6c /* Password unlock 1 */
0x02 0x24 0x11 0x86 /* Apply DCDC changes */
0x02 0x24 0x0b 0x6c /* Password unlock 2 */
0x02 0x24 0x11 0x86 /* Apply DCDC changes */
>;
/* Set OPP100 (1.10V) for VDD core on TPS65217 */
wake_sequence = /bits/ 8 <
0x02 0x24 0x0b 0x6d /* Password unlock 1 */
0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */
0x02 0x24 0x0b 0x6d /* Password unlock 2 */
0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */
0x02 0x24 0x0b 0x6c /* Password unlock 1 */
0x02 0x24 0x11 0x86 /* Apply DCDC changes */
0x02 0x24 0x0b 0x6c /* Password unlock 2 */
0x02 0x24 0x11 0x86 /* Apply DCDC changes */
>;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
