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? 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. 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.) > 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? For the TI AM335x, the source for M3 firmware is available and configurable[1]. However, I'd still rather see this done by the low-level platform code in linux, not offloaded to the firmware, but the linux vs. firmware decision orthogonal to how to define/probe the sequences that need to be sent to the regulator. Kevin [1] git://arago-project.org/git/projects/am33x-cm3.git -- 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
