On Thu, Aug 29, 2013 at 8:17 AM, Kevin Hilman [off-list ref] wrote:

Russ Dill [off-list ref] writes:

quoted

On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman [off-list ref] wrote:

quoted

[+Mark Brown for regulator suspend sequence ideas]

Russ Dill [off-list ref] writes:

quoted

On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe [off-list ref] wrote:

quoted

On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote:

[snip]

quoted

quoted

quoted

Shouldn't the TPS driver know how to generate this sequence? It seems
fragile to do voltage adjustments behind the back of the regulator
framework and the TPS driver. The wake-sequence values should match the
(in-memory) regulator configuration on resume (which may have been
changed by DVFS).

The sequence is both PMIC specific and board specific. Additionally,
the PMICs used aren't am335x specific. It would be nice to have the
regulator framework and the driver write all this out, but the
sequence is written out by the Cortex-M3 processor running some PM
firmware. Even if the code was changed to run on the A8, it'd have to
run from a small piece of SRAM.

So, why/how was the decision made to use the M3 instead of the MPU
running from SRAM?

As a firmware minimalist, I obviously prefer to do this from the MPU
side.  But also, because the M3 is reset every suspend sequence, this
becomes rather heavy to do from the M3.

After the feedback Vaibhav Bedia received on v2 of his suspend/resume
patchset for am335x, he decided to move many of the operations from
sleep33xx.S into the M3 firmware.

See the commit message here:
http://arago-project.org/git/projects/?p=am33x-cm3.git;a=commit;h=a972ce2f6

Was this feedback on the public lists?  That patch has never been posted
to linux-omap AFAICT.

quoted

I need to wait until after the PLLs are put into bypass, which is now
done in the M3 firmware. It also ends up being a lot easier to write
the I2C writer code there in C rather than in assembly in sleep33xx.S.

hmm, (carefully) written functions in C can still be copied to SRAM.  I
dont' see that as an obstacle.

quoted

quoted

Currently voltage scaling is only being proposed for suspend in this
series, but in theory it's possible from idle as well.  Doing this from
the MPU/SRAM seems much better suited for idle.

The M3 firmware will also handle any cpuidle modes deeper than just
putting SDRAM into self refresh. This is actually the only way of
doing things like turning the MPU domain off on am335x.

Yes, it will have to handle the MPU/interconnect off parts but other
than that, that's the only thing it *has* to do (well, and handle wakeup
from the deep state.)  The rest of the stuff being piled into the M3 is
a result of software/firmware design decisions AFAICT.  As I predicted
when I first saw this SoC design, the firmware is getting bigger and
bigger.  Initially it was argued that it would be tiny, and only handle
the things it had to do.  Now it's growing due to "convenience".  IMO,
this is a bad trend, and one that will make this code more and more
difficult to maintain upstream (assuming that's a goal.)

Do you mean upstream as in the firmware upstream, or upstream as in
the kernel upstream? Upstream kernel is really easy to maintain
because sleep33xx.S just puts the SDRAM into self-refresh.

The code to perform these transitions is going to exist, either in
kernel or in firmware. If you are looking for this to be maintainable
C code that is copied into SRAM, it will need to be built much like a
firmware, with it's elf sections being copied into SRAM properly. I'm
not sure how much it complicates things, but the code needs to be able
to run with the MMU on and MMU off. The C code would be a minimalized
duplication of much of what is already in mach-omap2. Because you are
proposing to split this up between A8 and M3, much of that code would
then be duplicated again within the M3 firmware.

And don't forget that am335x is just the first platform with such a PM scheme.

Because the M3 firmware already has to manage power domains, hwmods,
plls, and clockdomains, adding or removing which ones it handles
doesn't really change the size or complexity of the firmware. In fact,
because so much of the code is common code, moving this into kernel
would just mean making two copies of the firmware with different steps
to be run, one for the A8 SRAM, one for the M3.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html