Re: RFC: 2/5 System Device Driver Modifications

Vinicius Costa Gomes


"Thomas, Ramesh" <ramesh.thomas(a)> writes:

On Fri, 2016-03-11 at 14:59 -0300, Vinicius Costa Gomes wrote:

"Thomas, Ramesh" <ramesh.thomas(a)> writes:

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

What should be done:
1) Each native Zephyr kernel driver and shim driver (such as QMSI) shall

a) uint32_t suspend() - routine that will move any required device state
to RAM* with the following valid return values:
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

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
RAM* with the following valid return values:


2) Provide a name recognized by the device_get_binding() function, this
includes what are currently thought to be drivers such as timers,

*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.


Join to automatically receive all group messages.