[PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
khilman at linaro.org
Thu Aug 29 11:29:37 EDT 2013
On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown <broonie at kernel.org> 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 at linaro.org> 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
> 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. 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.
More information about the linux-arm-kernel