|
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
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.
|
|
|
Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> 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
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); 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.
Cheers, -- Vinicius
|
|
|
Kalowsky, Daniel <daniel.kalowsky@...>
Hey Vinicius,
toggle quoted messageShow quoted text
-----Original Message-----
From: Vinicius Costa Gomes [mailto:vinicius.gomes(a)intel.com]
Sent: Friday, March 11, 2016 9:59 AM
To: Thomas, Ramesh <ramesh.thomas(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: RFC: 2/5 System Device Driver Modifications
Hi,
"Thomas, Ramesh" <ramesh.thomas(a)intel.com> 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
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? That was the general idea. Or say a comms module has been idle and is now seeing some activity or connectivity suddenly arriving. 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);
It's not clear in the RFC how do plan to handle this. When I requested Ramesh add this, it was really an idea of pushing any policy decisions out from the kernel and into the PMA. In this case, if a device reports back that it is busy, the PMA can choose to: 1) Treat this as a failure, bail out, and report back that suspend has failed. 2) Spin until the device reports back success or failure and make the decision from there. 3) Put device into a list to recheck after shutting down other devices (if possible) 4) Ignore and move along. But again, these are all PM policy decisions that a Power Management Application should be making, not the kernel.
|
|
|
On Fri, 2016-03-11 at 14:59 -0300, Vinicius Costa Gomes wrote: Hi,
"Thomas, Ramesh" <ramesh.thomas(a)intel.com> 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
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.
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.
Cheers,
--
Vinicius
|
|
|
Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes: On Fri, 2016-03-11 at 14:59 -0300, Vinicius Costa Gomes wrote:
Hi,
"Thomas, Ramesh" <ramesh.thomas(a)intel.com> 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
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.
Cheers,
--
Vinicius
Cheers, -- Vinicius
|
|
|
