Quark SE: Implement PM reference application

[nashif]

Reported by Anselmo L. S. Melo:

Implement Quark SE specific sample applicatioin which application demonstrates how to interact with the PM subsystem and how to put the SoC in different power states. The application keeps transiting between all power states supported by Quark SE SoC.

(Imported from Jira ZEP-650)

[nashif]

by Andre Guedes:

Patches implementing this story have been merged upstream.

https://gerrit.zephyrproject.org/r/#/c/3014/ https://gerrit.zephyrproject.org/r/#/c/3016/ https://gerrit.zephyrproject.org/r/#/c/3012/

[nashif]

by Sharron LIU:

Andre Guedes , I have a few open points before closing this feature.

1. This sample app make direct calls to qmsi, instead of using Zephyr provided helper functions. Would like to learn the reasons behind.

2. The sample app program an RTC alarm (for wake up from sleep), followed by device_suspend(RTC). Adding this line to build_suspend_device_list(), to verify that RTC_0 is also in the suspend list: printk("%s\t", devices[i].config->name); Personally I would try avoid this in the PMA. Since the alarm behavior becomes uncertain after RTC is suspended.

[nashif]

by Andre Guedes:

Hi Sharron LIU ,

1. This sample app is Quark SE-specific and it aims to show PMA developers how to put the SoC and Host processor in all power states supported by Quark SE SoC. At the time we developed this sample app there were no APIs to put the SoC and Host processor in power states. Thus, since this sample PMA is Quark SE-specific and QMSI already provided APIs to handle power states, we used QMSI directly. BTW, we are currently discussing about changing Zephyr APIs to use QMSI implementation or simply remove them and use QMSI directly.

2. RTC device is on Always On (AON) domain so its registers aren't lost during sleep state. All device_suspend(RTC) does is simply save the RTC interrupt routing information (see drivers/rtc/rtc_qmsi.c). So the RTC alarm should work just fine (waking the system up). We have tested it several times and it was working fine. Did you find any issue?

[nashif]

by Mark Linkmeyer:

Sharron LIU , please assign the appropriate test label (Testable, TestbyDev, or NotTest) so it's known who needs to verify this story. Thx.

[nashif]

by Sharron LIU:

Andre Guedes , thanks for feedbacks.

At the time being it is not easy to tell whether a PMA developer prefer to use Zephyr facilities, though, a PMA app based on Zephyr will benefit when porting across various architecture and platforms, among which some are beyond quark platforms (like what i see today altera_max10, minnowboard). It may take efforts for Zephyr to abstract APIs and to facilitate that, but it is significant for Zephyr to provide that to my understand. For this sample app, as you pointed out, it target for quark_se specifically hence it make calls to QMSI. Also noticed Zephyr facilities are demonstrated by another sample app "zephyr/samples/power/power_mgr" already. Then I think this point can be closed. Thanks!

Regarding device_suspend(RTC), I wonder if DCG (dynamic clock gating) is supported by quark MCU? If yes, we should expected bit "CCU_RTC_PCLK_EN_SW" of "CCU_PERIPH_CLK_GATE_CTL" cleared, refer to Table 415 Page 473 of [1]

As for documentation clarify device behavior in suspended state, I think the top level description is fine in [2].

• Save device states.
• Gate clocks.
• Turn off peripherals.

However, platform specific behavior should be documented in API header files. Like, whether quark platform support RTC clock gating? whether RTC alarm keep counting in suspended state?

[1] http://www.intel.com/content/www/us/en/embedded/products/quark/mcu/se-soc/quark-c1000-datasheet.html [2] https://www.zephyrproject.org/doc/subsystems/power_management.html

[nashif]

by ethan gao:

I saw the SHIM device driver is merely save device states with Deep Sleep policy and restore them after wake-up. regarding Gate clock, AFAIK, now only UART and SPI ACG(Autonomous Clock Gating) support on Quark SE SoC via clearing CCU_XXX_PCLK_EN_SW to 0.

[nashif]

by Andre Guedes:

Sharron LIU , yes, dynamic clock gating is supported in Quark SE however I don't think those bits you pointed are expected to be cleared. According to the table you referred, those bits are persistent (see 'P' legends on table) so they shouldn't be clear during sleep.

Documenting soc-specific behavior on generic driver API which is common to all SoCs might not be the best place. Maybe this information could be in wiki or something like that and refer the datasheet for more details. Anyways, I'll bring your feedback to the engineer team, thanks!

ethan gao , you're right. None of shim drivers support 'SYS_PM_DEVICE_SUSPEND_ONLY' option (which would map into clock gate I think) at the moment.

[nashif]

by Sharron LIU:

OK, let's follow up the clock gating topic (including RTC) in the "SYS_PM_DEVICE_SUSPEND_ONLY" option.

For this quark_se sample app, verified sample app demonstrating quark_se power transition among (CPU_C1, CPU_C2, CPU_C2LP, SOC_SLEEP, SOC_DEEP_SLEEP).

Points to be addressed in separated topics:

1. this sample app now make calls directly to qmsi driver. Andre is aware of this. Discussion on going whether the quark_se PMA can use qmsi directly.
2. clock gating should map to other power policies which is followed by GH-613.

For topic within this story scope has been implemented. Closing this issue.