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... > 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.
Attachment:
signature.asc
Description: Digital signature
