Re: RFC: 2/5 System Device Driver Modifications


Kalowsky, Daniel <daniel.kalowsky@...>
 

Hey Vinicius,

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

Join devel@lists.zephyrproject.org to automatically receive all group messages.