[PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support

Russ Dill Russ.Dill at ti.com
Thu Aug 29 13:47:04 EDT 2013


On Thu, Aug 29, 2013 at 10:30 AM, Mark Brown <broonie at kernel.org> wrote:
> On Thu, Aug 29, 2013 at 09:31:55AM -0700, Russ Dill wrote:
>> On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown <broonie at kernel.org> wrote:
>
>> > 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...
>
>> On all am335x platforms, the lower operating point for core voltage
>> cannot be reached without first disabling the DDR controller, and
>> programming it into a lower power mode. For DDR3 platforms, no such
>> lower power mode is available and the lower operating point for core
>> voltage can only be reached with the memory controller disabled.
>
> So this is done from cpuidle rather than system suspend.

It is done for system suspend. It isn't possible to do this in a
cpuidle use case as the memory controller would need to come out of
idle automatically to service DMA requests.

>> It certainly is possible that some bizarre I2C regulator may mix in
>> regulator voltage and some other state into one I2C register. In the
>> case of such a platform, setting the lower operating point would not
>> be supported.
>
> This isn't particularly bizzare, there is no technical reason why a
> register in the PMIC has to be given over completely to setting the
> voltage and indeed there are PMICs in mainline right now which don't do
> that - if you've got 16 bit registers it's probably not going to take
> the entire 16 bits to encode the voltage range.
>
>> > 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.
>
>> I'm not sure what you mean by "actual sequence". Maybe if I show you a
>> couple examples, it will be more clear:
>
> I mean describe the intended sequence of events in the system rather
> than the raw register commands to accomplish them.

I'm still not sure what you mean.

> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



More information about the linux-arm-kernel mailing list