On Thu, Aug 29, 2013 at 08:29:37AM -0700, Kevin Hilman wrote:

On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown [off-list ref] wrote:

quoted

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...

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.
-------------- 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/20130829/36460f8a/attachment.sig>