On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Tue, Aug 27, 2013 at 06:05:34PM -0700, Russ Dill wrote: >> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: > >> > The framework already has a concept of suspend voltage, suspend mode >> > etc. Maybe it needs some generalizing so low-level platform code could >> > query the framework for the sequence so it can be done late in platform >> > idle/suspend paths. Especially for regmap drivers, this seems feasible. > >> Yes, my main hesitation for going down this path is possible lack of >> support for such an interface upstream. > > 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? > > Generally for suspend if the sequencing is being done by the processor > it's been handled by the drivers for the components in question. For > sequencing beyond that you're into hardware features which aren't all > that regular sadly and often aren't controllable either. It sounds like > this is the latter case but the thing that manages some of the late > power down stages does so using a firmware we can rewrite? So the AM335X processor has a small M3 coprocessor attached to it. The M3 coprocessor is in charge of performing many of the sleep and resume transition steps. It has a 16k code space for firmware. The CM3 coprocessor has access to most of the same registers the primary AM335X processor has access to (PM registers, clock registers, I2C controller, etc). For the deepest sleep modes, the core power supply can have its voltage reduced, but only after several steps by the CM3 coprocessor have been performed. The core power supply voltage must be reduced by the CM3 coprocessor. The core regulator is controlled by I2C on all the AM335X platforms that I am aware of, but different platforms have different I2C regulators. The path I'm taking in this patchset is to just put the board specific I2C sequences necessary for the CM3 coprocessor to write out into the devicetree. I've made it as generic as I can so that other platforms with similar issues can reuse the bindings. Because of the limitations of the firmware size and the desire not to have some sort of byte code, this is a write only sequence. Kevin Hilman is suggesting some way to query the regulator framework for this sequence. There would be some call to the regulator framework that would return a series of I2C commands that would be necessary to program a regulator to a specific voltage. It would be called twice, once for the suspend voltage, once for the resume voltage. The regulator framework would then call into the driver that sets that voltage, and by some method query the driver for the necessary I2C sequence, either by some special new call, or some regmap magic. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
