Problem Statement: Not all Zephyr kernel drivers provide the same interfaces.
Why this is a problem: ----------------------------- The Zephyr kernel currently has devices that are essential for core OS functions (such as APICs and timers), but provide no public API means for accessing them. Without any consistent method to access device drivers on the platform, it becomes very difficult to achieve power targets.
What should be done: ----------------------------- 1) Each native Zephyr kernel driver and shim driver (such as QMSI) shall support:
a) uint32_t suspend() - routine that will move any required device state data to RAM* with the following valid return values: - DEV_OK - DEV_BUSY - DEV_FAIL
I am thinking about the case when DEV_BUSY is returned, I am considering this would happen, for example, in the SPI case when there's a transfer going on, right?
I guess there are at least two alternatives: - The power management process has some kind of heuristic for retrying; - Having some mechanism for communicating the power management that "now I am ready to suspend" (from what I understand, this was in the original power management proposal);
The power manager application should be able to handle that case. It can either retry after trying other drivers, ignore that driver or abort suspend.
The callback is not going to help because _sys_soc_suspend is already called in the kernel idle task and it cannot go any more idle than that waiting for a callback to come. It is better off retrying the driver until it gets it to suspend.
Ah, I see. Thanks.
It's not clear in the RFC how do plan to handle this.
b) uint32_t resume() - routine that will retrieve any device state data from RAM* with the following valid return values:
- DEV_OK - DEV_FAIL
2) Provide a name recognized by the device_get_binding() function, this includes what are currently thought to be drivers such as timers, IOAPIC, and LOAPIC.
*The power management process is not expected to power down system RAM (it will most likely stay in selective suspend).
The size of the device data is dependent upon an individual device, and therefore the system integrator must be wary of the number of devices being utilized.
Device suspend flow: Device Drivers at suspend shall: - Device state shall be saved to memory and maintained across a PM event - Turning off the device clock - Return appropriate error code
Device resume flow: Device Drivers at resume shall: - Restore to state saved in memory - Turn on the device clock - Return appropriate error code
Device domain experts will be needed to implement the proper methods for suspending and resuming each device.
