[RFC 0/2] am33xx 0.950V core sleep mode

[RFC 0/2] am33xx 0.950V core sleep mode

[Russ Dill]

This patchset adds support for setting vdd core to 0.95V during
suspend. I wanted to get some comments on the DT usage and also
the location of the code, in sleep33xx.S. Since the am33xx PM code
is not yet merged, the patchset is based on ti-linux-3.8.y kernel
located at https://git.ti.com/ti-linux-kernel/ti-linux-kernel.

am33xx processors have a special VDD core operating point that can
lower power consumption, but the operating point has many
restrictions. One of the restrictions is that it does not support
any DDR3 clock rates, meaning that the memory controller must be
disabled to enter this operating point. For DDR2 systems, the
clock rate must be changed, which can only be done from internal
memory.

For these reasons, the mode is most useful during suspend. The
change must be done after the memory controller has been disabled.
The memory controller is disabled as the last step in the suspend
sequence, within sleep33xx.S.

The patchset basically adds a small I2C controller to sleep33xx.S,
allowing simple I2C messages to be sent to anything on the I2C1 bus.
It can support any am33xx platform so long as VDD core can be
controlled via simple writes on the I2C1 bus.

Since am33xx is a device tree platform, I needed to find a way to
integrate this into DT. I put the sleep and wake sequences as arrays
of binary bytes in the I2C1 node. I'm not sure where else it would
fit better, but I'm open to suggestions.

An example sequence is included for Beaglebone, where this patchset
has been tested.

Russ Dill (2):
  ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support
  ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone.

 arch/arm/boot/dts/am335x-bone.dts |  25 +++++-
 arch/arm/mach-omap2/pm33xx.c      | 108 ++++++++++++++++++++++
 arch/arm/mach-omap2/pm33xx.h      |  23 +++++
 arch/arm/mach-omap2/sleep33xx.S   | 184 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 339 insertions(+), 1 deletion(-)

-- 
1.8.1.2

[RFC 1/2] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support

[Tony Lindgren]

* Russ Dill <Russ.Dill@ti.com> [130501 12:07]:
> This patch adds the ability to write an I2C sleep sequence from
> SRAM just before WFI, and a wake sequence just after control is passed
> from the M3. This is useful for adjusting voltages during sleep that cannot
> be lowered while SDRAM is active.
> 
> Each sequence is a series of I2C transfers in the form:
> 
> u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ...
> 
> The length indicates the number of bytes to transfer, including the register
> address. The length of the sequence is limited by the amount of space
> reserved in SRAM, 127 bytes.
> 
> The sequences are taken from the i2c1 node in the device tree. The property
> name for the sleep sequence is "sleep_sequence" and the property name for
> the wake sequence is "wake_sequence". Each property should be an array of
> bytes.
> 
> No actions are performed if the properties are not present in the device
> tree.

Looks like you should make that into just a regular device driver that lives
under drivers/ somewhere?

Regards,

Tony

[RFC 1/2] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support

[Russ Dill]

On Wed, May 1, 2013 at 4:26 PM, Tony Lindgren <tony@atomide.com> wrote:
>
> * Russ Dill <Russ.Dill@ti.com> [130501 12:07]:
> > This patch adds the ability to write an I2C sleep sequence from
> > SRAM just before WFI, and a wake sequence just after control is passed
> > from the M3. This is useful for adjusting voltages during sleep that cannot
> > be lowered while SDRAM is active.
> >
> > Each sequence is a series of I2C transfers in the form:
> >
> > u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ...
> >
> > The length indicates the number of bytes to transfer, including the register
> > address. The length of the sequence is limited by the amount of space
> > reserved in SRAM, 127 bytes.
> >
> > The sequences are taken from the i2c1 node in the device tree. The property
> > name for the sleep sequence is "sleep_sequence" and the property name for
> > the wake sequence is "wake_sequence". Each property should be an array of
> > bytes.
> >
> > No actions are performed if the properties are not present in the device
> > tree.
>
> Looks like you should make that into just a regular device driver that lives
> under drivers/ somewhere?
>
> Regards,
>
> Tony

This code has to be copied to, and run from SRAM. What would that even
look like? Additionally, there is also code under drivers/ that
manages this piece of hardware, i2c-omap.c. The code in this patch
differs in that it accesses no system memory, no stack, only knows how
to write, and it runs without interrupts.

[RFC 1/2] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support

[Tony Lindgren]

* Russ Dill <Russ.Dill@ti.com> [130501 16:43]:
> On Wed, May 1, 2013 at 4:26 PM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > Looks like you should make that into just a regular device driver that lives
> > under drivers/ somewhere?
> 
> This code has to be copied to, and run from SRAM. What would that even
> look like? Additionally, there is also code under drivers/ that
> manages this piece of hardware, i2c-omap.c. The code in this patch
> differs in that it accesses no system memory, no stack, only knows how
> to write, and it runs without interrupts.

Well we should move to using the generic drivers/misc/sram.c, so
you should be able to load the code to SRAM using that. Then you
can probably register some callback function based on the compatible
flag with i2c-omap.c?

Regards,

Tony