How many WFI instructions are needed for entering Stop mode ?

[aurélienmartin]

Hi,

  I have some troubles understanding both the Reference Manual (among other documentations), and those forums (fora ?). Right now I'm focusing on getting in and out of (LP)STOP mode, so I'll ask here my questions on this subject, and suggest you to consider releasing something lke an application note to clarify the workings of such modes, for others.

1 - To enter one such mode, be it STOP or LPSTOPn, we need to execute a WFI instruction. More precisely, in section 14.3.4 (Wait mode) of the RM, we find :

Wait mode is entered when the GPC_LPMR register is configured for Wait mode and the WFI (Wait For Interrupt) instruction is executed on the core.

The core ? Which core ? And later :

WFI for an individual core can be executed and GPC_LPMR may not be configured to enter into chip Wait mode. In dual-core configurations, the application can configure WFI to put a single core into halt. Other peripherals can continue operating at the configured frequencies if GPC_LPMR is configured to 00b, i.e., Run mode.

Ok, so if I'm to configure GPC_LPMR as 10b (STOP mode), and make any core execute WFI, I stall them both ? Then in CCM registers' description, we find :

M_CORE0_WFI : Mask WFI of core0 for entering low power mode

0 WFI of core0 is not masked

1 WFI of core0 is masked

And others of that ilk, for Core1 WFI, SCU Idle, and L2CC Idle. Please what does "mask" mean, here ? Do I get to mask one core's WFI, and so not fall into STOP mode when it occurs ? Or is it so that I actually need both WFI, simultaneously, to enter STOP mode (as suggested here), and that masking one would permit me to make do without it, and thus with only one core WFIing ? Actually, right now I'm more a believer of the second solution, according to the note just above those bits' description :

Setting all the bits CCM_CLPCR[M_CORE0_WFI], CCM_CLPCR[M_CORE1_WFI], CCM_CLPCR[M_SCU_IDLE], and Chapter 10 Clock Controller Module (CCM) Vybrid Reference Manual, Rev. 5, 07/2013 Freescale Semiconductor, Inc. 657 CCM_CLPCR[M_L2CC_IDLE] will result in stop mode or low power stop mode depending upon GPC.

But I really would appreciate some certainty.

2 - In LPSTOPn mode, power is gated for almost every module, including IOMUXC and GPIO. Does it mean that the Vybrid loses control of all its outputs ? That's certainly what I'm experiencing, but then again, I'm not quite sure of actually having reached LPSTOPnmode (see point 3, and point 1 for that matter). If that is so, do I have to pull down the CKE signal of the SDRAM bus, to allow selfrefresh to continue while the controller sleeps ? But this signal is pulled up on the TWR, is it and functional requirement ? So do I need to come up with some hardware trick to switch between pullup and pulldown depending on the state of my IOs ?

3 - When I try to go into LPSTOP2 mode (managing only the A5 core, with a vanilla Linux 3.19-rc4-XX), then to get out of it, what I experience is a software reset (ie. call of SRC_GPR0(SRC_GPR1). Is that the expected way out ? Or did I mess up somewhere ? For STOP mode or for LPSTOPn mode, am I supposed to continue execution after the WFI instruction, on wakeup, or to jump at [SRC_GPR0] ?

Thank you for your lights,

Aurélien Martin

[falstaff · Accepted solution]

Hi Aurélien,

I can not answer all your questions with certainty, but some of it might still be helpful:

To 1.

One WFI instructions of the cores is enough to put the SoC into STOP/LPSTOP mode. Afaik, when a WFI instruction is executed, a signal will be generated to the CCM, which will, depending on the mask field of the core , put the SoC in low power mode, e.g. when you mask Core0, a WFI instruction of the A5 would not put the system into a low power mode. When both CPU's are "not masked" (=> 0), I can put the system into low power mode with only one WFI instruction from the A5 (however, in my test case the M4 was not running).

To 2.

Yes, Vybrid loses control of all its outputs, expect the Wakup pads. See Chapter 3 Chip Configuration, under Chapter 3.4, Wake-up Unit, those pins can be controlled through the wake up unit (looks like only pull-up is possible).

The two required DDR3 signals CKE and RESET need to be pulled by the hardware to the expected state during self-refresh mode, see the Design Checklist table in the Hardware Development Guide.

To 3.

Afaik, that is the expected way out for LPSTOP modes, e.g. when PD1 is powered off. PD1 power gates the whole platform, which includes the CPU cores. However, in STOP mode, the execution will continue after the WFI instruction.

So you are interested in LPSTOP modes in vanilla Linux? I have some preliminary patches in my repo with which I successfully put a 3.18 kernel into LPSTOP2, but those are quite raw right now. Let me know if you are interested.

--

Stefan

[aurélienmartin]

Hi Stefan,

Thank you for your quick answers (and thank you for the accent :smileyhappy:).

1 - Ok, that was also my later conclusion after having fiddled with the mask and having seen no differences in behaviour whatsoever. Then I assume this note above CCM_CLPCR's description is just "Well, masking everything doesn't make any sense, so let it trigger (LP)STOP mode instead..."

2 - Thank you for the pointer, as a software guy I am "not quite aware of such documents" :smileywink:. I will pass it on to my hardware colleagues. It appears though that "Any Vybrid's terminations (such as 50 ohms) should not be present; simulation should be performed to ensure signal integrity." may be a requirement we're not able to meet here... I wonder whether those wakeup pads could be of some help to me. I've not found the pullups' value, and I don't exepect them to be high, since they're really meant to stabilize unconnected signals. But perhpas they could be enough to switch the state of a transistor of some sort, and replace a permanent pullup on CKE by a convenient pulldown...

3 - Thanks for that also. Currently I manage to get in and out of LPSTOP, but I don't wake up from STOP, if that's actually where I land when I intend to. The code is actually the same, with the only difference of PD1 power gating. (I don't clock gate individual peripherals for now. But perhaps if I did it would work better.) Perhaps there's a messy attempt at handling the wakeup interrupt, or perhaps is it still masked at some level, while LPSTOP powergates that level. But now that I know with certainty where to wait for normal execution return, debugging will be easier. (I also assume I'm right in my belief that MMU is kept configured through clock-only gating, and that I'm left with virtual addressing when waking up from STOP.)

Actually I also successfully put my 3.19-rc4 kernel into LPSTOP2 (and that's also raw and messy for now, especially my assembly part, though I based the whole thing on the code for IMX6, which I find quite elegant). The main problem is that the hardware I'm currently working on (Freescale's Tower and Phytec's Cosmic) doesn't allow me as is to keep data in DDR3. I also don't have handled registers save/restore at suspend/resume inside the platform drivers, but that's another problem.

Anyway thank you for your help, and fare well.

Edit: Actually, the design alluded to, with pulldown on CKE, pullup on RST, and no termination resistors is implemented on the TWR rev H, which eases things a lot. :smileyhappy:

[falstaff]

Hi Aurélien,

You are welcome. We even have such a character on our keyboards here :-)

To 3

Yeah, not all hardware have that fix, but the latest Tower should have it. Also, our module will have it starting with V1.2. To verify our design, I already tested my suspend code with a prepared module, and it worked fine with DDR3 memory retained.

https://www.toradex.com/computer-on-modules/colibri-arm-family/freescale-vybrid-VF6xx

--

Stefan