Date   

Re: [RFC] Provide a generic interface for getting the SOC ID and version

Liu, Baohong
 

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 3:41 PM
To: devel(a)lists.zephyrproject.org; Liu, Baohong <baohong.liu(a)intel.com>
Subject: Re: [RFC] Provide a generic interface for getting the SOC ID and
version

On Fri, 2016-07-15 at 18:50 +0000, Liu, Baohong wrote:

Actually that's not what this API meant to achieve. Some confusion in
the text;
the purpose is to provide a generic API for retrieving this
information. How the information
is obtained is implementation detail and in fact, As much possible
should be build time
decided as you pointe it out.
Since we've established we should do this at build time, why not make
this a Kconfig or some other #define instead of adding C code which
will add to the footprint?
Yes, the implementation should be through #define.

As the requirement from the ZEP is to get this information from a HAL (e.g QMSI), we
can require HAL does this using #define. (current QMSI implements this as C function
though so that requires it changed to fit this requirement).

Andrew


Re: [RFC] Provide a generic interface for getting the SOC ID and version

Boie, Andrew P
 

On Fri, 2016-07-15 at 18:50 +0000, Liu, Baohong wrote:
 
Actually that's not what this API meant to achieve. Some confusion in
the text;
the purpose is to provide a generic API for retrieving this
information. How the information
is obtained is implementation detail and in fact, As much possible
should be build time
decided as you pointe it out.
Since we've established we should do this at build time, why not make
this a Kconfig or some other #define instead of adding C code which
will add to the footprint?

Andrew


Re: [RFC] Provide a generic interface for getting the SOC ID and version

Kumar Gala
 

On Jul 15, 2016, at 1:50 PM, Liu, Baohong <baohong.liu(a)intel.com> wrote:

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 10:56 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID and
version

Good questions. My understanding the main idea is the scalability on
reading these information from registers at run time vs. hardcoding them
at build time.
Scalability across HW with the same binary is not one of Zephyr's goals. We
really try to do everything at build time to make the OS as small and fast as
possible. This is why dynamic interrupts were removed, for example.

So given a choice between doing something at runtime or coding it at build
time, to date the preference has been for the latter.
Actually that's not what this API meant to achieve. Some confusion in the text;
the purpose is to provide a generic API for retrieving this information. How the information
is obtained is implementation detail and in fact, As much possible should be build time
decided as you pointe it out.
I think the application of this API needs to be much clearer. What use cases are their from the application side?

- k


Re: [RFC] Provide a generic interface for getting the SOC ID and version

Liu, Baohong
 

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 10:56 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID and
version

Good questions. My understanding the main idea is the scalability on
reading these information from registers at run time vs. hardcoding them
at build time.
Scalability across HW with the same binary is not one of Zephyr's goals. We
really try to do everything at build time to make the OS as small and fast as
possible. This is why dynamic interrupts were removed, for example.

So given a choice between doing something at runtime or coding it at build
time, to date the preference has been for the latter.
Actually that's not what this API meant to achieve. Some confusion in the text;
the purpose is to provide a generic API for retrieving this information. How the information
is obtained is implementation detail and in fact, As much possible should be build time
decided as you pointe it out.


Andrew


Re: [RFC] Provide a generic interface for getting the SOC ID and version

Boie, Andrew P
 

Good questions. My understanding the main idea is the scalability on
reading these information from registers at run time vs. hardcoding them
at build time.
Scalability across HW with the same binary is not one of Zephyr's goals. We really try to do everything at build time to make the OS as small and fast as possible. This is why dynamic interrupts were removed, for example.

So given a choice between doing something at runtime or coding it at build time, to date the preference has been for the latter.

Andrew


Re: [RFC] Provide a generic interface for getting the SOC ID and version

Liu, Baohong
 

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Thursday, July 14, 2016 10:50 PM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID and
version

There can be a need to provide a generic interface API for getting the SOC
ID,
version, and other identifying data. These data can be useful for an
application to use to generate unique Information (for example, MAC
addresses).
Hi Baohong,

Can you give a little more detail about use-cases? Seems like the information
being queried is not unique per-device data but identification values for the
HW.
In Zephyr pretty much everything is known at build time, so I would to learn
more about why we think we need runtime support for this.
Good questions. My understanding the main idea is the scalability on reading
these information from registers at run time vs. hardcoding them at build time.

The MAC case mentioned may be a bit confusing (but if it in fact was a usage,
it should also reply on additional information, not just using only SoC id or rev
number in deriving a unique MAC, as you pointed out).



Regards,
Andrew


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 3
[ZEP-553] SDP for Bluetooth BR/EDR
https://jira.zephyrproject.org/browse/ZEP-553

[ZEP-554] samples/drivers/aon_counter check readme file
https://jira.zephyrproject.org/browse/ZEP-554

[ZEP-555] correct libgcc not getting linked for CONFIG_FLOAT=y on ARM
https://jira.zephyrproject.org/browse/ZEP-555


UPDATED JIRA items within last 24 hours: 1
[ZEP-235] Provide an interface for cpu/soc id and version
https://jira.zephyrproject.org/browse/ZEP-235


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 9
[ZEP-273] (Fixed) nios2: implement flashing scripts
https://jira.zephyrproject.org/browse/ZEP-273

[ZEP-506] (Fixed) nios2: support baremetal boot and XIP on Altera MAX10
https://jira.zephyrproject.org/browse/ZEP-506

[ZEP-274] (Fixed) nios2: document GDB debugging procedure
https://jira.zephyrproject.org/browse/ZEP-274

[ZEP-387] (Fixed) Installed SDK version should be easy to find
https://jira.zephyrproject.org/browse/ZEP-387

[ZEP-429] (Fixed) CONFIG_NEWLIB_LIBC unusable with Zephyr SDK 0.8
https://jira.zephyrproject.org/browse/ZEP-429

[ZEP-518] (Fixed) SPI not working on Arduino101
https://jira.zephyrproject.org/browse/ZEP-518

[ZEP-218] (Fixed) [drivers/nble][PTS_TEST] Fix responding with the wrong error codes to the Prepare Write Request
https://jira.zephyrproject.org/browse/ZEP-218

[ZEP-221] (Fixed) [drivers/nble][PTS_TEST] Implement Execute Write Request handler
https://jira.zephyrproject.org/browse/ZEP-221

[ZEP-431] (Fixed) newlib should be configured with --disable-newlib-supplied-syscalls
https://jira.zephyrproject.org/browse/ZEP-431


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/3282 : libc: Add assert.h to minimal libc
- https://gerrit.zephyrproject.org/r/3286 : net: tinydtls: Use assert.h from minimal libc
- https://gerrit.zephyrproject.org/r/3283 : nios2: map all sys_write* to 32-bit version
- https://gerrit.zephyrproject.org/r/3284 : altera_max10: enable and use 16550 UART
- https://gerrit.zephyrproject.org/r/3285 : drivers/nble: Fix not setting user input expected flag
- https://gerrit.zephyrproject.org/r/3278 : net/yaip: revert merge
- https://gerrit.zephyrproject.org/r/3280 : uart: qmsi: Adds device suspend/resume to uart_qmsi device
- https://gerrit.zephyrproject.org/r/3279 : rtc: qmsi: Adds device suspend/resume to rtc_qmsi device
- https://gerrit.zephyrproject.org/r/3277 : samples: drivers: gpio: add quark d2000 in testcase.ini

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3275 : drivers/nble: Update nble_version structure
- https://gerrit.zephyrproject.org/r/3014 : samples: Add Quark SE power management application
- https://gerrit.zephyrproject.org/r/2994 : Bluetooth: L2CAP: Split security changed handler for BR/EDR
- https://gerrit.zephyrproject.org/r/3273 : Bluetooth: Add eddystone sample
- https://gerrit.zephyrproject.org/r/2998 : Bluetooth: L2CAP: Handle BR/EDR configuration deferred by GAP
- https://gerrit.zephyrproject.org/r/2997 : Bluetooth: L2CAP: Introduce security requirements on CoC
- https://gerrit.zephyrproject.org/r/2903 : microkernel: Fix fifo buffer name generation in DEFINE_FIFO
- https://gerrit.zephyrproject.org/r/2915 : nios2: optionally print cause code reason
- https://gerrit.zephyrproject.org/r/2869 : power_mgmt: Add Deep Sleep support in sample PM app
- https://gerrit.zephyrproject.org/r/2876 : power_mgmt: Create arch/soc specific helper functions
- https://gerrit.zephyrproject.org/r/2868 : power_mgmt: Adds device suspend/resume to loapic timer
- https://gerrit.zephyrproject.org/r/2797 : sensor: add sensor_value_sprintf helper function
- https://gerrit.zephyrproject.org/r/3016 : samples: power/quark_se: Add support for Sleep states
- https://gerrit.zephyrproject.org/r/3161 : ext qmsi: Enable linking to qm_init.o
- https://gerrit.zephyrproject.org/r/3015 : x86: crt0: Remove 'je copyDataDone' from CONFIG_XIP block
- https://gerrit.zephyrproject.org/r/2962 : build: Make sure sysgen related header files get updated
- https://gerrit.zephyrproject.org/r/3276 : ext qmsi: Fix registers definition for LPSS
- https://gerrit.zephyrproject.org/r/3271 : build: Improve usage of the ISSM toolchain
- https://gerrit.zephyrproject.org/r/2841 : Scripts: Check all CONFIG_* in the code are defined into a Kconfig file
- https://gerrit.zephyrproject.org/r/2373 : testcases: stub for x86 core on Quark SE
- https://gerrit.zephyrproject.org/r/3160 : samples/usb: Fix build for usb_dfu example

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3281 : nios2: remove nios2e-zephyr
- https://gerrit.zephyrproject.org/r/2996 : Bluetooth: L2CAP: Set BR/EDR CoC channel as connected
- https://gerrit.zephyrproject.org/r/2995 : Bluetooth: L2CAP: Mark finishing CoC configuration on BR/EDR
- https://gerrit.zephyrproject.org/r/2079 : Bluetooth: L2CAP: Introduce CoC channel states
- https://gerrit.zephyrproject.org/r/3122 : quark_se: Correct UART_IRQ_FLAGS to IOAPIC_LEVEL
- https://gerrit.zephyrproject.org/r/3005 : drivers/pinmux: Change spaces by tabs in the pinmap table
- https://gerrit.zephyrproject.org/r/2888 : doc: Update floating point docs for ARM
- https://gerrit.zephyrproject.org/r/3159 : doc: rearrange builders to fail sooner
- https://gerrit.zephyrproject.org/r/3157 : Bluetooth: Fix changing advertising random address when scanning
- https://gerrit.zephyrproject.org/r/3274 : Bluetooth: Track if active scan is being perfomed


Re: [RFC] Provide a generic interface for getting the SOC ID and version

Boie, Andrew P
 

There can be a need to provide a generic interface API for getting the SOC ID,
version, and other identifying data. These data can be useful for an
application to use to generate unique Information (for example, MAC
addresses).
Hi Baohong,

Can you give a little more detail about use-cases? Seems like the information being queried is not unique per-device data but identification values for the HW.
In Zephyr pretty much everything is known at build time, so I would to learn more about why we think we need runtime support for this.


Regards,
Andrew


Re: [RFC] Power Management Infrastructure

Thomas, Ramesh
 

On 07/14/2016 06:17 AM, Rahamim, Hezi wrote:
Hi Ramesh'

Please see my comments below.

Regards,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Thursday, July 14, 2016 10:32
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

On 7/13/2016 11:40 PM, Rahamim, Hezi wrote:
Hi Dimitriy,

The get_state is there only for symmetry and good practice.
As mentioned below the power manager service will probably not use it as it is not efficient to do get_state to all devices to know all the devices states...
The more important part of the RFC is adding the set_state function and the device policies.
That made me think why we originally came up with 2 functions when one was enough. Probably we thought the same way - to keep symmetry. Problem is that we will keep getting more needs and we will either add more functions to device_pm_ops or will have to change existing ones.

How about having one function that can be used for all possible device PM purposes using a control code? Something like following :-

int device_pm_control(device, flags);

flags = (CONTROL_CODE | SYSTEM_POWER_STATE | DEVICE_POWER_STATE)

CONTROL_CODE = {SET_POWER_STATE, GET_POWER_STATE, ...} DEVICE_POWER_STATE = {device PM states} SYSTEM_POWER_STATE = {system power policies}

(We can add additional parameters if flags param is overloaded)

returns value based on CONTROL_CODE
e.g. returns device power state if CONTROL_CODE == GET_POWER_STATE

(We probably don't need device_pm_ops if we have only one function.)

[HR] Looks good. If the PM service will be designed as a driver than it can use the SYSTEM_POWER_STATE and a device driver will use the DEVICE_POWER_STATE.


***I also have some questions inline below***



Thanks for the comment,
Hezi

-----Original Message-----
From: Dmitriy Korovkin [mailto:dmitriy.korovkin(a)windriver.com]
Sent: Thursday, July 14, 2016 00:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: [RFC] Power Management Infrastructure

Hi Hezi,
I think RFC needs to be extended with the description of the idea of controlling power state of each device (if I got you correctly).
Without it the need of
int (*get_state)(struct device *device, int device_pm_policy); looks very unclear.
If all you need is to provide more that two states, then set_state() looks quite enough.

Regards,

Dmitriy Korovkin

On 16-07-13 12:11 PM, Rahamim, Hezi wrote:
Hi Ramesh,

Please see my comments below/

Thanks for the comments,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Wednesday, July 13, 2016 09:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Power Management Infrastructure

On 7/12/2016 2:03 AM, Rahamim, Hezi wrote:
Hi all,

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

between two driver states (suspend and resume). Drivers may have
more than two
Currently suspend and resume are not actually states but a notification of the state transition. There is a second argument to those functions that specify the current policy for which the transition is happening.


states (i.e. D-states) and can traverse between those states. The
state change

today is limited only from active to suspend while there can be
cases of other

transitions requested by the application.

Please look at the below suggested device power states E.g.
transition between

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an
application or

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

int (*suspend)(struct device *device, int pm_policy);

int (*resume)(struct device *device, int pm_policy);

};

Proposed changes

===============

First proposed change is to have a set state and get state driver
functions

instead of the suspend resume functions:

struct device_pm_ops {

int (*set_state)(struct device *device, int
device_pm_policy);

int (*get_state)(struct device *device, int
device_pm_policy);

};

The set_state function will behave according to the state transition
of a specific

driver. E.g. transition from active state to suspend state in a UART
device will

save device states and gate the clock.
The proposal, as I understand, is to use the pm hooks to actively
control the power states instead of using them as just notifications
of the SOC's power transitions. Considering this, we had one power
policy called "device_suspend_only". That is open to be broken down
into more device specific power states.

[HR] You are correct, we intend to use the pm driver hooks to
actively control the device Power states. We will use the Zephyer's
current power policies to indicate the system power state. As you
mentioned, when devices will not be in active state the system can still be at "device_suspend_only" state.
Do you see any issues with the apps/drivers keeping the PM service updated of the device's current state in real time? What about race conditions? Complexity of communication framework?
[HR] The need of communication framework and device state database lock may be needed. For example, inter processor communication may be needed if in a specific SoC
there are shared power resources between two cores (in AtP3 we may avoid that...)



The get_state function will enable the Power Manager service to know
the state

of each driver thus enable it to configure the SoC power behavior.
The set_state function looks ok. It is the same as the current
suspend but with the name change. The purpose of the name change is
to add a corresponding get_state. The RFC is not giving much details
of the use of the get_state function.

I assume there is a need for the PM service to build a device tree,
with power hierarchy. It would be helpful if you could explain how
this function fits in your larger design of the PM service's power
policy management of the devices.

[HR] I will give an example:
A user application decides to suspend the I2C and the SPI devices.
The application will then call the corresponding set_state functions of these devices.
The set_state functions will perform the store of the relevant device
state and gate the device clock. In the next idle time the _sys_soc_suspend will be called.
This will trigger the power manager service which will decide what
should be done to optimize the power (clock gate a branch or change the system power state.
The decision of the power manager service will be based on the
devices states which can be obtained also by using the get_state functions.

Since the PM service is expected to have communication established
with all components in the system, wouldn't it know what state each
device is set to? Querying each device and building a tree every time
there is an opportunity to suspend, may take some time causing delay in suspend.

[HR] You are correct, using the get_state function will lead to a
less optimal Power manager service and it will need to use a more optimized method.
However, it is a good practice to have this function as the
application may want to query the device state.

Second proposed change is to add the below device power states:

Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE

--------------------------------------------

Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE

-------------------------------------------------------

Device context is preserved by the HW and need not be restored by
the driver.

The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE

------------------------------------------------

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context
lost

by the hardware.

The device can be powered down.

The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE

---------------------------------------

Power has been fully removed from the device. The device context is
lost

when this state is entered, so the OS software will reinitialize the
device

when powering it back on.

Device may not wake itself as the SoC need to reinitialize the device.
The description of the power states here sounds like they are
notifications. It sounds like some other component is setting the
power state and notifies using these values and the drivers do
save/restore or other operations based on the notification. Are the
drivers expected to gate clocks, turn off peripherals etc. in these notifications?

[HR] These device power states serve two purposes:
1. The drivers are expected to perform all the power/clock changes It
can perform according to the selected power state and do not
influence other drivers.
2. The power manager service will use the drivers states to decide on
system power policy to go to (it can also stay in
SYS_PM_DEVICE_SUSPEND_ONLY but to optimize the clock gating scheme)
Would these become part of a specification that all device drivers would need to implement? In this scheme, the PM responsibilities are shared between PM Service, various apps and drivers. So some plan needs to be in place to ensure all of them cooperate as expected.
[HR] You are right, there is a need to define the PM responsibilities of the PM service, drivers and apps. However, this RFC was written to add the ability to support more than two device states, define the available states and to enable transition between them.
We will be happy to contribute also to define the above.
The device PM states look ok to me. They are architecture independent
and the drivers can map them to device specific operations.

I think this RFC should be part of other RFCs that define the bigger
picture of how it is used. As I see it, the kind of device PM you
propose can function independent of system idle. In my opinion, it would
be good to define it independent of system power management. The 2 will
coordinate, but should not be a requirement. That way, either
infrastructure can be used independently by users. Also there would be
implementations that would want to do all device PM in the PM service
for various reasons.



The initial part of the RFC does mention the application can set the
power state of the device and that is what the proposed set_state
function also suggests.

Do they serve both purposes? May be an example of how the device's
power state is actively changed and who and when does it, with
respect to these notifications, would help.

[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with DEVICE_PM_SUSPEND_STATE.
When idle comes the PM service is called and see that it can close the SPI and I2C PLL.
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.
Will the PM service also put devices to suspend state, or only the apps will do it? Looks like the PM Service will never enter Deep Sleep if any device is on - any exceptions?
[HR] Only apps will do that. The PM service can decide in some cases to go to deep sleep even if specific device is active (e.g. the device is located in the always on power domain). The decision to change power state is SoC specific.

In the above example, the system had to go to idle for the PLL to get turned off. If you had a central scheme to turn off clocks then the PLL could have been turned off when both i2c and spi got turned off. Just an observation.
[HR] There are indeed several ways to solve this and there will be a need to choose the best one for the specific SoC.

Comments/concerns welcome.

Thanks,

Hezi

--------------------------------------------------------------------
- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material
for the sole use of the intended recipient(s). Any review or
distribution by others is strictly prohibited. If you are not the
intended recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: [RFC] Power Management Infrastructure

Thomas, Ramesh
 

On 07/14/2016 01:36 AM, D'alton, Alexandre wrote:
Hi,

Please find comments below.

Regards,
Alex.

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Thursday, July 14, 2016 9:32 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

On 7/13/2016 11:40 PM, Rahamim, Hezi wrote:
Hi Dimitriy,

The get_state is there only for symmetry and good practice.
As mentioned below the power manager service will probably not use it as it is
not efficient to do get_state to all devices to know all the devices states...
The more important part of the RFC is adding the set_state function and the
device policies.

That made me think why we originally came up with 2 functions when one was
enough. Probably we thought the same way - to keep symmetry. Problem is that
we will keep getting more needs and we will either add more functions to
device_pm_ops or will have to change existing ones.

Because, we agreed on the fact that suspend resume were managed by a central entity and was the only needed control over the drivers. I think this is still true.
That does not explain why 2 functions are better than 1. In the
scenario you mention, all that is needed is a way to notify the device
of a power state transition.



[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with
DEVICE_PM_SUSPEND_STATE.
When idle comes the PM service is called and see that it can close the SPI and
I2C PLL.
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.
In my opinion the clock tree needs to be managed completely separately, and in a completely independent way of the pm state.
Each driver mark that they use their clock when active and mark that they do not need it when not active. One can consider that an enabled clock gate is equivalent to a deep sleep forbidden, but that won't be true always on clock gates.


Will the PM service also put devices to suspend state, or only the apps will do it?
Looks like the PM Service will never enter Deep Sleep if any device is on - any
exceptions?

In the above example, the system had to go to idle for the PLL to get turned off.
If you had a central scheme to turn off clocks then the PLL could have been
turned off when both i2c and spi got turned off. Just an observation.


[RFC] Provide a generic interface for getting the SOC ID and version

Liu, Baohong
 

Hi,

There can be a need to provide a generic interface API for getting the SOC ID, version, and
other identifying data. These data can be useful for an application to use to generate
unique Information (for example, MAC addresses).

This is based on ZEP-235.

Proposed Interface
***************

/**
* @brief Read SoC id
*
* @retval soc id. The information is SoC specific.
*/
static uint32_t soc_id_get(void);

For example, on Quark SE, this would return the value from the SCSS identification register.
On ARM based SOC, for example Atmel sam3, this would be the chip id from the id code
register.

/**
* @brief Read soc version
*
* @retval soc version. A platform dependent 32 bit version information.
*/
static uint32_t soc_version_get(void);

Depending on the SoC, this can include different types of version information for example,
SOC version, major, and minor revision numbers, etc.

For example, for Quark SE, this would be the rev number from the SCSS rev register.
For ARM based SOC, for example Atmel sam3, this will be the version value from id code
register.

Welcome feedback/comments or any concerns.

Thanks,
Baohong


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 5
[ZEP-512] Add suspend/resume support for some core devices to enable Deep Sleep support in PMA
https://jira.zephyrproject.org/browse/ZEP-512

[ZEP-511] Add Deep Sleep support in PMA
https://jira.zephyrproject.org/browse/ZEP-511

[ZEP-469] Ethernet/IPv4/TCP: net_receive & net_reply in server mode
https://jira.zephyrproject.org/browse/ZEP-469

[ZEP-497] Ethernet/IPv4/TCP: failed to get free buffer
https://jira.zephyrproject.org/browse/ZEP-497

[ZEP-518] SPI not working on Arduino101
https://jira.zephyrproject.org/browse/ZEP-518


CLOSED JIRA items within last 24 hours: 1
[ZEP-317] (Duplicate) Send datagrams over UDP sockets to an arbitrary address and port, without requiring the socket to know about specific remote addresses.
https://jira.zephyrproject.org/browse/ZEP-317


RESOLVED JIRA items within last 24 hours: 3
[ZEP-489] (Fixed) nios2: handle unimplemented multiply/divide instructions
https://jira.zephyrproject.org/browse/ZEP-489

[ZEP-49] (Fixed) x86: unify separate SysV and IAMCU code
https://jira.zephyrproject.org/browse/ZEP-49

[ZEP-58] (Fixed) investigate use of -fomit-frame-pointer
https://jira.zephyrproject.org/browse/ZEP-58


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/3161 : ext qmsi: Enable linking to qm_init.o
- https://gerrit.zephyrproject.org/r/3271 : build: Fix usage of the ISSM toolchain
- https://gerrit.zephyrproject.org/r/3276 : ext qmsi: Fix registers definition for LPSS
- https://gerrit.zephyrproject.org/r/3275 : drivers/nble: Update nble_version structure
- https://gerrit.zephyrproject.org/r/3274 : Bluetooth: Track if active scan is being perfomed
- https://gerrit.zephyrproject.org/r/3157 : Bluetooth: Fix changing advertising random address when scanning
- https://gerrit.zephyrproject.org/r/3273 : Bluetooth: Add eddystone sample
- https://gerrit.zephyrproject.org/r/3220 : Revert "net: yaip: Add ICMP protocol header struct"
- https://gerrit.zephyrproject.org/r/3236 : Revert "net: tests: Add unit test for IP and MAC address printing"
- https://gerrit.zephyrproject.org/r/3270 : Revert "net: yaip: Initial commit for new IP stack"
- https://gerrit.zephyrproject.org/r/3267 : Revert "net: yaip: Use same prefix in new IP stack Kconfig"
- https://gerrit.zephyrproject.org/r/3265 : Revert "net: Add generic network interface header"
- https://gerrit.zephyrproject.org/r/3263 : Revert "net: yaip: Add network address information to interface"
- https://gerrit.zephyrproject.org/r/3262 : Revert "net: yaip: Add multicast address to network interface"
- https://gerrit.zephyrproject.org/r/3259 : Revert "net: yaip: Add TX fifo to network interface"
- https://gerrit.zephyrproject.org/r/3258 : Revert "net: yaip: Refactored RX fiber init"
- https://gerrit.zephyrproject.org/r/3255 : Revert "net: yaip: Add nbuf buffer API"
- https://gerrit.zephyrproject.org/r/3251 : Revert "net: Show only uIP debug options when needed"
- https://gerrit.zephyrproject.org/r/3254 : Revert "slip: Add driver for host to qemu connectivity"
- https://gerrit.zephyrproject.org/r/3249 : Revert "net: yaip: Execute net_init() automatically"
- https://gerrit.zephyrproject.org/r/3248 : Revert "net: yaip: Add net_if_get_by_link_addr() util function"
- https://gerrit.zephyrproject.org/r/3199 : Revert "net: yaip: Add util to check if IPv4 address is part of subnet"
- https://gerrit.zephyrproject.org/r/3205 : Revert "net: tests: Tweak the IP address test to use new net_if API"
- https://gerrit.zephyrproject.org/r/3198 : Revert "net: yaip: Add capabilities flag to net_if API"
- https://gerrit.zephyrproject.org/r/3247 : Revert "net: yaip: Add Kconfig option for compiling IPv4 support"
- https://gerrit.zephyrproject.org/r/3203 : Revert "net: yaip: Add utility function returning IPv4 broadcast address"
- https://gerrit.zephyrproject.org/r/3202 : Revert "net: yaip: net_ipaddr_copy() macro was too fragile"
- https://gerrit.zephyrproject.org/r/3201 : Revert "net: yaip: Macro to compare two IPv4 addresses"
- https://gerrit.zephyrproject.org/r/3268 : Revert "net: yaip: Add ntohl() and related macros"
- https://gerrit.zephyrproject.org/r/3269 : Revert "net: yaip: Add defines for various IP protocol header lengths"
- https://gerrit.zephyrproject.org/r/3238 : Revert "net: yaip: Add debug function to print MAC address"
- https://gerrit.zephyrproject.org/r/3196 : Revert "net: yaip: Added IPv4 ARP support"
- https://gerrit.zephyrproject.org/r/3246 : Revert "net: yaip: Add send() to net_if API"
- https://gerrit.zephyrproject.org/r/3200 : Revert "net: yaip: Add utils to set IPv4 netmask and gateway in net_if"
- https://gerrit.zephyrproject.org/r/3204 : Revert "net: yaip: Do not remove fragments if main buffer is not removed"
- https://gerrit.zephyrproject.org/r/3266 : Revert "net: yaip: Compile new stack if enabled"
- https://gerrit.zephyrproject.org/r/3194 : Revert "slip: Support TAP functionality"
- https://gerrit.zephyrproject.org/r/3264 : Revert "net: yaip: apps: Create a skeleton echo-server for new IP stack"
- https://gerrit.zephyrproject.org/r/3191 : Revert "net: yaip: Make echo-server to use documentation IPv4 addresses"
- https://gerrit.zephyrproject.org/r/3193 : Revert "net: yaip: Setting preferred status to manually added IPv4 address"
- https://gerrit.zephyrproject.org/r/3261 : Revert "net: yaip: Add IPv6 prefixes to network interface"
- https://gerrit.zephyrproject.org/r/3260 : Revert "net: yaip: Let new IP stack know the debug Kconfig options"
- https://gerrit.zephyrproject.org/r/3244 : Revert "net: yaip: Refactor debug printing in net_if"
- https://gerrit.zephyrproject.org/r/3197 : Revert "net: tests: Add tests for IPv4 netmask, gw and subnet compare"
- https://gerrit.zephyrproject.org/r/3195 : Revert "net: tests: Unit tests for IPv4 ARP code"
- https://gerrit.zephyrproject.org/r/3241 : Revert "net: yaip: Start to receive network packets"
- https://gerrit.zephyrproject.org/r/3243 : Revert "net: yaip: Enable compilation of net_if.c"
- https://gerrit.zephyrproject.org/r/3188 : Revert "net: tests: Fixed the ARP test"
- https://gerrit.zephyrproject.org/r/3257 : Revert "net: yaip: Add function that feeds data to RX fifo"
- https://gerrit.zephyrproject.org/r/3186 : Revert "net: yaip: IP checksum calculation should ignore ll header"
- https://gerrit.zephyrproject.org/r/3256 : Revert "net: yaip: Compile IPv6 and IPv4 address conditionally"
- https://gerrit.zephyrproject.org/r/3181 : Revert "net: yaip: Provide separate header file for ethernet"
- https://gerrit.zephyrproject.org/r/3185 : Revert "net: yaip: ICMPv4 checksum calculation fixed"
- https://gerrit.zephyrproject.org/r/3252 : Revert "net: yaip: Add net_analyze_stack() macro"
- https://gerrit.zephyrproject.org/r/3242 : Revert "net: Fix Kconfig warning"
- https://gerrit.zephyrproject.org/r/3184 : Revert "net: tests: Additional tests for ICMPv4 checksum verification"
- https://gerrit.zephyrproject.org/r/3183 : Revert "net: yaip: Handle ARP messages"
- https://gerrit.zephyrproject.org/r/3253 : Revert "net: yaip: Fix compilation error in net_if.h"
- https://gerrit.zephyrproject.org/r/3240 : Revert "net: yaip: Add net_context to compilation"
- https://gerrit.zephyrproject.org/r/3180 : Revert "net: yaip: Trivial comment fixes in header files"
- https://gerrit.zephyrproject.org/r/3178 : Revert "net: yaip: Fix __packed attribute, use shorter alias"
- https://gerrit.zephyrproject.org/r/3250 : Revert "net: yaip: Add Kconfig option for compiling IPv6 support"
- https://gerrit.zephyrproject.org/r/3230 : Revert "net: yaip: Utilities to set and lookup interface IPv6 addresses"
- https://gerrit.zephyrproject.org/r/3179 : Revert "net: yaip: Add UDP header"
- https://gerrit.zephyrproject.org/r/3245 : Revert "net: yaip: Start to use logging macros from sys_log.h"
- https://gerrit.zephyrproject.org/r/3177 : Revert "net: yaip: Use generic wrapper for semaphore give operation"
- https://gerrit.zephyrproject.org/r/3175 : Revert "net: yaip: The core initialize ARP layer relevantly"
- https://gerrit.zephyrproject.org/r/3176 : Revert "net: yaip: Include toolchain related header for aliases"
- https://gerrit.zephyrproject.org/r/3174 : Revert "net: yaip: Shorten IPv4/6 config options"
- https://gerrit.zephyrproject.org/r/3235 : Revert "net: yaip: Receive IPv6 packet"
- https://gerrit.zephyrproject.org/r/3234 : Revert "net: yaip: Drop received source mcast IPv6 packets"
- https://gerrit.zephyrproject.org/r/3231 : Revert "net: yaip: Add utility functions to check IPv6 addresses"
- https://gerrit.zephyrproject.org/r/3233 : Revert "net: yaip: Add extension header and bitmap fields to nbuf"
- https://gerrit.zephyrproject.org/r/3229 : Revert "net: tests: Add IPv6 address manipulation unit tests"
- https://gerrit.zephyrproject.org/r/3232 : Revert "net: yaip: Add utility func to return IP address type as a string"
- https://gerrit.zephyrproject.org/r/3239 : Revert "net: yaip: Add statistics gathering support"
- https://gerrit.zephyrproject.org/r/3171 : Revert "net: yaip: Add an L2 layer"
- https://gerrit.zephyrproject.org/r/3225 : Revert "net: tests: Add more IPv6 address getters unit tests"
- https://gerrit.zephyrproject.org/r/3167 : Revert "net: yaip: Add NET_ASSERT() macro"
- https://gerrit.zephyrproject.org/r/3166 : Revert "net: yaip: Save some bytes on net_if logic"
- https://gerrit.zephyrproject.org/r/3228 : Revert "net: yaip: Add IPv4 addresses to network interface"
- https://gerrit.zephyrproject.org/r/3227 : Revert "net: tests: Add IPv4 address unit tests"
- https://gerrit.zephyrproject.org/r/3226 : Revert "net: yaip: IPv6 address utility funcs for network interface"
- https://gerrit.zephyrproject.org/r/3224 : Revert "net: yaip: Network interface code compiles ok for IPv4 and IPv6"
- https://gerrit.zephyrproject.org/r/3223 : Revert "net: yaip: Receive IPv4 packet"
- https://gerrit.zephyrproject.org/r/3221 : Revert "net: yaip: Fixed the IP/UDP/ICMP getter macros"
- https://gerrit.zephyrproject.org/r/3222 : Revert "net: yaip: Added API documentation to IP address check functions"
- https://gerrit.zephyrproject.org/r/3219 : Revert "net: yaip: Move IP address print funcs to separate file"
- https://gerrit.zephyrproject.org/r/3218 : Revert "net: yaip: Network interface sets default IPv6 hop limit"
- https://gerrit.zephyrproject.org/r/3217 : Revert "net: yaip: Renamed network data receive function"
- https://gerrit.zephyrproject.org/r/3215 : Revert "net: yaip: Network interface needs own TX fiber stack"
- https://gerrit.zephyrproject.org/r/3216 : Revert "net: yaip: Add net_send_data() that sends data to network"
- https://gerrit.zephyrproject.org/r/3214 : Revert "net: yaip: Add net_hexdump() utility to print network data"
- https://gerrit.zephyrproject.org/r/3213 : Revert "net: yaip: Add IP packet checksum calculation utilities"
- https://gerrit.zephyrproject.org/r/3209 : Revert "net: yaip: Add unit tests for ICMPv6 handler"
- https://gerrit.zephyrproject.org/r/3211 : Revert "net: tests: Unit tests for network utilities"
- https://gerrit.zephyrproject.org/r/3210 : Revert "net: yaip: Add ICMPv6 handler"
- https://gerrit.zephyrproject.org/r/3212 : Revert "net: yaip: Add debugging option for network utilities"
- https://gerrit.zephyrproject.org/r/3208 : Revert "net: yaip: Process received ICMPv6 messages"
- https://gerrit.zephyrproject.org/r/3189 : Revert "net: yaip: Use net_nbuf_ll() macro to get into arp header"
- https://gerrit.zephyrproject.org/r/3207 : Revert "net: yaip: Process received ICMPv4 messages"
- https://gerrit.zephyrproject.org/r/3206 : Revert "net: yaip: Add utility function to return default network interface"
- https://gerrit.zephyrproject.org/r/3192 : Revert "net: yaip: Only accept ARP reply if we requested data"
- https://gerrit.zephyrproject.org/r/3187 : Revert "net: yaip: Clarified the debug print about packet length"
- https://gerrit.zephyrproject.org/r/3190 : Revert "net: yaip: Add helper to get pointer to link local header"
- https://gerrit.zephyrproject.org/r/3170 : Revert "net: yaip: Re-factor Kconfig and move ARP to a better place"
- https://gerrit.zephyrproject.org/r/3182 : Revert "net: yaip: Setting static IP addresses for echo-server"
- https://gerrit.zephyrproject.org/r/3173 : Revert "net: yaip: Add an helper to queue a buffer in a net_if instance"
- https://gerrit.zephyrproject.org/r/3172 : Revert "net: yaip: Make net_core.h include the least amount of necessary header"
- https://gerrit.zephyrproject.org/r/3169 : Revert "net: yaip: Removing capabilities() from net_if api"
- https://gerrit.zephyrproject.org/r/3168 : Revert "net: yaip: Tiny comment fix"
- https://gerrit.zephyrproject.org/r/3162 : Revert "net: yaip: Print available DATA buffers during nbuf alloc"
- https://gerrit.zephyrproject.org/r/3164 : Revert "net: yaip: Moved ARP helper macro to arp.h"
- https://gerrit.zephyrproject.org/r/3165 : Revert "net: yaip: Add comment explaining net_core's verdict values"
- https://gerrit.zephyrproject.org/r/3163 : Revert "net: yaip: Make sure that RX is started before TX"
- https://gerrit.zephyrproject.org/r/3160 : samples/usb: Fix build for usb_dfu example
- https://gerrit.zephyrproject.org/r/3237 : Revert "net: yaip: Add debug function to print IP address"
- https://gerrit.zephyrproject.org/r/3159 : doc: rearrange builders to fail sooner

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3129 : net: tests: Add unit tests for neighbor cache
- https://gerrit.zephyrproject.org/r/2797 : sensor: add sensor_value_sprintf helper function
- https://gerrit.zephyrproject.org/r/3122 : quark_se: Correct UART_IRQ_FLAGS to IOAPIC_LEVEL
- https://gerrit.zephyrproject.org/r/2079 : Bluetooth: L2CAP: Introduce CoC channel states
- https://gerrit.zephyrproject.org/r/2868 : power_mgmt: Add device suspend/resume support to some core devices
- https://gerrit.zephyrproject.org/r/2995 : Bluetooth: L2CAP: Mark finishing CoC configuration on BR/EDR
- https://gerrit.zephyrproject.org/r/2888 : doc: Update floating point docs for ARM
- https://gerrit.zephyrproject.org/r/2996 : Bluetooth: L2CAP: Set BR/EDR CoC channel as connected
- https://gerrit.zephyrproject.org/r/3014 : samples: Add Quark SE power management application
- https://gerrit.zephyrproject.org/r/2327 : aon counter: Use locking mechanism to guard critical regions of API call
- https://gerrit.zephyrproject.org/r/2915 : nios2: optionally print cause code reason
- https://gerrit.zephyrproject.org/r/2841 : Scripts: Check all CONFIG_* in the code are defined into a Kconfig file
- https://gerrit.zephyrproject.org/r/2919 : ext qmsi: Build the power states support from QMSI
- https://gerrit.zephyrproject.org/r/3140 : net: yaip: Depending on debug flags the stdio.h is not included
- https://gerrit.zephyrproject.org/r/3147 : net: yaip: Change how the L2 header space is reserved in net_buf
- https://gerrit.zephyrproject.org/r/3145 : net: tests: Fix unit test for IP utils
- https://gerrit.zephyrproject.org/r/3141 : net: yaip: Fix arp.h so that net_arp_init() is found
- https://gerrit.zephyrproject.org/r/3143 : net: yaip: Changed the IP and ll address debug prints
- https://gerrit.zephyrproject.org/r/3139 : net: yaip: Print statistics using SYS_LOG
- https://gerrit.zephyrproject.org/r/3146 : net: yaip: Make sure that either IPv4 or IPv6 gets selected
- https://gerrit.zephyrproject.org/r/3144 : net: tests: Fix unit test for IP addresses
- https://gerrit.zephyrproject.org/r/3138 : net: yaip: Network stack analyzer uses now the SYS_LOG sub-system
- https://gerrit.zephyrproject.org/r/3136 : net: yaip: The NET_DEBUG symbol must not be set in header file
- https://gerrit.zephyrproject.org/r/3137 : net: yaip: Do not overwrite SYS_LOG_DOMAIN
- https://gerrit.zephyrproject.org/r/3142 : net: tests: Fix unit test for ARP
- https://gerrit.zephyrproject.org/r/3149 : net: yaip: Re-send ARP when needed
- https://gerrit.zephyrproject.org/r/2565 : fs: [DO NOT MERGE] Add bottom layer disk io for FAT FS
- https://gerrit.zephyrproject.org/r/3148 : net: yaip: Add utility to remove ipv4 address from iface
- https://gerrit.zephyrproject.org/r/2566 : fs: [DO NOT MERGE] Add a sample app to demo file system
- https://gerrit.zephyrproject.org/r/3134 : net: yaip: Process ICMPv6 packets only if IPv6 is enabled
- https://gerrit.zephyrproject.org/r/2876 : power_mgmt: Create arch/soc specific helper functions
- https://gerrit.zephyrproject.org/r/3135 : net: yaip: Use debugging net_buf unref function
- https://gerrit.zephyrproject.org/r/3133 : net: yaip: Refactor various network init functions
- https://gerrit.zephyrproject.org/r/3131 : net: yaip: No need to do ARP for IPv6 network packet
- https://gerrit.zephyrproject.org/r/2869 : power_mgmt: Add Deep Sleep support in sample PM app
- https://gerrit.zephyrproject.org/r/3130 : net: yaip: The IP protocol type needs to be set in L2 layer
- https://gerrit.zephyrproject.org/r/3132 : net: yaip: Buffer leak if net_if_send_data() returns NET_DROP
- https://gerrit.zephyrproject.org/r/3156 : slip: Fix the debug print
- https://gerrit.zephyrproject.org/r/3128 : net: yaip: Add a neighbor cache needed in IPv6
- https://gerrit.zephyrproject.org/r/3127 : net: yaip: Add IPv6 address network interface utilities
- https://gerrit.zephyrproject.org/r/3126 : net: yaip: Add IPv6 utilities for address manipulation
- https://gerrit.zephyrproject.org/r/3151 : net: yaip: Set the l2 src/dst addresses in nbuf
- https://gerrit.zephyrproject.org/r/3155 : net: yaip: Write ethernet header when using slip and tap
- https://gerrit.zephyrproject.org/r/3153 : net: yaip: Set IP protocol type when sending ethernet packet
- https://gerrit.zephyrproject.org/r/3154 : net: yaip: Make sure ethernet l2 sets src and dst addresses
- https://gerrit.zephyrproject.org/r/3152 : net: yaip: Set the ll src and dst addresses in ethernet l2 driver
- https://gerrit.zephyrproject.org/r/3150 : net: yaip: Add ethernet address helpers
- https://gerrit.zephyrproject.org/r/2893 : Test: including second line with blank spaces and a tab.
- https://gerrit.zephyrproject.org/r/3123 : net: yaip: Add struct to store link layer address
- https://gerrit.zephyrproject.org/r/2890 : Test2: Modify name in signature
- https://gerrit.zephyrproject.org/r/1533 : ci: test: footprint: increase
- https://gerrit.zephyrproject.org/r/2563 : CI TEST: do not merge: test leading space in kconfig files
- https://gerrit.zephyrproject.org/r/2891 : Correct: Commit message with full compliance
- https://gerrit.zephyrproject.org/r/2886 : thisnotcontaininfo
- https://gerrit.zephyrproject.org/r/2738 : test
- https://gerrit.zephyrproject.org/r/3125 : net: yaip: Changing IPv4 address comparer to a function
- https://gerrit.zephyrproject.org/r/3124 : net: yaip: Use const for static pre-defined IPv6 addresses

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3272 : Bluetooth: SMP: Fix disabling debug logs
- https://gerrit.zephyrproject.org/r/3158 : net: buf: Minor cleanups & fixes to the API documentation
- https://gerrit.zephyrproject.org/r/2871 : Bluetooth: Align the NBLE firmware version and upgrade SD
- https://gerrit.zephyrproject.org/r/3013 : x86: crt0: Fix '_sys_soc_resume' type declaration
- https://gerrit.zephyrproject.org/r/3121 : quark_d2000: Update UART_IRQ_FLAGS for the board
- https://gerrit.zephyrproject.org/r/3067 : _loapic_isr_vector_get: fix implementation
- https://gerrit.zephyrproject.org/r/3066 : quark_se: make EOI operations atomic
- https://gerrit.zephyrproject.org/r/3065 : nios2: _Swap(): fix C calling issue
- https://gerrit.zephyrproject.org/r/2953 : x86: merge IAMCU and SYS V core arch code
- https://gerrit.zephyrproject.org/r/3083 : net: yaip: Add helper to get pointer to link local header
- https://gerrit.zephyrproject.org/r/3087 : net: yaip: IP checksum calculation should ignore ll header
- https://gerrit.zephyrproject.org/r/3079 : slip: Support TAP functionality
- https://gerrit.zephyrproject.org/r/3080 : net: yaip: Setting preferred status to manually added IPv4 address
- https://gerrit.zephyrproject.org/r/3082 : net: yaip: Make echo-server to use documentation IPv4 addresses
- https://gerrit.zephyrproject.org/r/3073 : net: yaip: Add utils to set IPv4 netmask and gateway in net_if
- https://gerrit.zephyrproject.org/r/3089 : net: tests: Additional tests for ICMPv4 checksum verification
- https://gerrit.zephyrproject.org/r/3078 : net: tests: Unit tests for IPv4 ARP code
- https://gerrit.zephyrproject.org/r/3068 : net: tests: Tweak the IP address test to use new net_if API
- https://gerrit.zephyrproject.org/r/3074 : net: yaip: Add util to check if IPv4 address is part of subnet
- https://gerrit.zephyrproject.org/r/3076 : net: tests: Add tests for IPv4 netmask, gw and subnet compare
- https://gerrit.zephyrproject.org/r/3088 : net: yaip: ICMPv4 checksum calculation fixed
- https://gerrit.zephyrproject.org/r/3070 : net: yaip: Add utility function returning IPv4 broadcast address
- https://gerrit.zephyrproject.org/r/3077 : net: yaip: Added IPv4 ARP support
- https://gerrit.zephyrproject.org/r/3092 : net: yaip: Provide separate header file for ethernet
- https://gerrit.zephyrproject.org/r/3081 : net: yaip: Only accept ARP reply if we requested data
- https://gerrit.zephyrproject.org/r/3069 : net: yaip: Do not remove fragments if main buffer is not removed
- https://gerrit.zephyrproject.org/r/3086 : net: yaip: Clarified the debug print about packet length
- https://gerrit.zephyrproject.org/r/3071 : net: yaip: net_ipaddr_copy() macro was too fragile
- https://gerrit.zephyrproject.org/r/3085 : net: tests: Fixed the ARP test
- https://gerrit.zephyrproject.org/r/3075 : net: yaip: Add capabilities flag to net_if API
- https://gerrit.zephyrproject.org/r/3093 : net: yaip: Trivial comment fixes in header files
- https://gerrit.zephyrproject.org/r/3084 : net: yaip: Use net_nbuf_ll() macro to get into arp header
- https://gerrit.zephyrproject.org/r/3072 : net: yaip: Macro to compare two IPv4 addresses
- https://gerrit.zephyrproject.org/r/3091 : net: yaip: Setting static IP addresses for echo-server
- https://gerrit.zephyrproject.org/r/3090 : net: yaip: Handle ARP messages
- https://gerrit.zephyrproject.org/r/3095 : net: yaip: Fix __packed attribute, use shorter alias
- https://gerrit.zephyrproject.org/r/3094 : net: yaip: Add UDP header
- https://gerrit.zephyrproject.org/r/3096 : net: yaip: Use generic wrapper for semaphore give operation
- https://gerrit.zephyrproject.org/r/3097 : net: yaip: Include toolchain related header for aliases
- https://gerrit.zephyrproject.org/r/3061 : net: Restructured Ethernet driver menu
- https://gerrit.zephyrproject.org/r/1871 : Bluetooth: Get the included service 128bit UUID
- https://gerrit.zephyrproject.org/r/3120 : net: buf: Add more big endian helpers
- https://gerrit.zephyrproject.org/r/3119 : net: buf: Add helpers to use net_buf_simple stack variables
- https://gerrit.zephyrproject.org/r/3099 : net: yaip: The core initialize ARP layer relevantly
- https://gerrit.zephyrproject.org/r/3098 : net: debug: Indent properly some config options.
- https://gerrit.zephyrproject.org/r/3100 : net: yaip: Shorten IPv4/6 config options
- https://gerrit.zephyrproject.org/r/3105 : net: yaip: Re-factor Kconfig and move ARP to a better place
- https://gerrit.zephyrproject.org/r/3101 : slip: Fix compiler warnings
- https://gerrit.zephyrproject.org/r/3108 : net: yaip: Add NET_ASSERT() macro
- https://gerrit.zephyrproject.org/r/3102 : net: yaip: Add an helper to queue a buffer in a net_if instance
- https://gerrit.zephyrproject.org/r/3103 : net: yaip: Make net_core.h include the least amount of necessary header
- https://gerrit.zephyrproject.org/r/3104 : net: yaip: Add an L2 layer
- https://gerrit.zephyrproject.org/r/3107 : net: yaip: Tiny comment fix
- https://gerrit.zephyrproject.org/r/3106 : net: yaip: Removing capabilities() from net_if api
- https://gerrit.zephyrproject.org/r/3010 : doc: filter doc with repo script
- https://gerrit.zephyrproject.org/r/3109 : net: yaip: Save some bytes on net_if logic


Re: [RFC] Zephyr Shell Enhancement

Luiz Augusto von Dentz
 

Hi Yael,

On Wed, Jul 13, 2016 at 2:05 PM, Avramovich, Yael
<yael.avramovich(a)intel.com> wrote:
Zephyr Shell Enhancement

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



========

Overview

========

Current shell implementation:

• Current Shell implementation is based on UART.

It uses one UART for console (UART number is determined by config
file).



• Console device driver initialization priority:

Console has to be initialized after the UART driver it uses.



• When the shell is initialized, it starts the shell as a fiber and

initialize UART console.



• Current shell implementation supplies shell utilities only for a
single

module.



=====

Goals

=====

1. Multiple and dynamic usage in modules level:

----------------------------------------------------------

Ability to add multiple modules to shell commands array.

Each module should be added dynamically by its config file.



2. Dynamic usage of the shell:

------------------------------------

Ability to enable / disable shell service.

If it is enabled (according to .Kconfig), basic framework shell commands

are also available for use.



3. Memory consumption:

------------------------------

Shell commands array should be allocated exactly according to the number
of

entities that actually use the shell.



4. Shell format:

------------------

Use one of the following (Error message is shown in case of a wrong
usage):

- ENTITY COMMAND

- help

- help ENTITY

- help ENTITY COMMAND

One of the entities is “FW”, for the Framework module.
Just have a command to select the module you want to operate, e.g.
select-module bluetooth, that way one don't have to keep entering the
entity name always. The prompt can also reflect the current module in
use.


Re: [RFC] Power Management Infrastructure

Rahamim, Hezi
 

Hi Ramesh'

Please see my comments below.

Regards,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Thursday, July 14, 2016 10:32
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

On 7/13/2016 11:40 PM, Rahamim, Hezi wrote:
Hi Dimitriy,

The get_state is there only for symmetry and good practice.
As mentioned below the power manager service will probably not use it as it is not efficient to do get_state to all devices to know all the devices states...
The more important part of the RFC is adding the set_state function and the device policies.
That made me think why we originally came up with 2 functions when one was enough. Probably we thought the same way - to keep symmetry. Problem is that we will keep getting more needs and we will either add more functions to device_pm_ops or will have to change existing ones.

How about having one function that can be used for all possible device PM purposes using a control code? Something like following :-

int device_pm_control(device, flags);

flags = (CONTROL_CODE | SYSTEM_POWER_STATE | DEVICE_POWER_STATE)

CONTROL_CODE = {SET_POWER_STATE, GET_POWER_STATE, ...} DEVICE_POWER_STATE = {device PM states} SYSTEM_POWER_STATE = {system power policies}

(We can add additional parameters if flags param is overloaded)

returns value based on CONTROL_CODE
e.g. returns device power state if CONTROL_CODE == GET_POWER_STATE

(We probably don't need device_pm_ops if we have only one function.)

[HR] Looks good. If the PM service will be designed as a driver than it can use the SYSTEM_POWER_STATE and a device driver will use the DEVICE_POWER_STATE.


***I also have some questions inline below***



Thanks for the comment,
Hezi

-----Original Message-----
From: Dmitriy Korovkin [mailto:dmitriy.korovkin(a)windriver.com]
Sent: Thursday, July 14, 2016 00:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: [RFC] Power Management Infrastructure

Hi Hezi,
I think RFC needs to be extended with the description of the idea of controlling power state of each device (if I got you correctly).
Without it the need of
int (*get_state)(struct device *device, int device_pm_policy); looks very unclear.
If all you need is to provide more that two states, then set_state() looks quite enough.

Regards,

Dmitriy Korovkin

On 16-07-13 12:11 PM, Rahamim, Hezi wrote:
Hi Ramesh,

Please see my comments below/

Thanks for the comments,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Wednesday, July 13, 2016 09:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Power Management Infrastructure

On 7/12/2016 2:03 AM, Rahamim, Hezi wrote:
Hi all,

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

between two driver states (suspend and resume). Drivers may have
more than two
Currently suspend and resume are not actually states but a notification of the state transition. There is a second argument to those functions that specify the current policy for which the transition is happening.


states (i.e. D-states) and can traverse between those states. The
state change

today is limited only from active to suspend while there can be
cases of other

transitions requested by the application.

Please look at the below suggested device power states E.g.
transition between

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an
application or

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

int (*suspend)(struct device *device, int pm_policy);

int (*resume)(struct device *device, int pm_policy);

};

Proposed changes

===============

First proposed change is to have a set state and get state driver
functions

instead of the suspend resume functions:

struct device_pm_ops {

int (*set_state)(struct device *device, int
device_pm_policy);

int (*get_state)(struct device *device, int
device_pm_policy);

};

The set_state function will behave according to the state transition
of a specific

driver. E.g. transition from active state to suspend state in a UART
device will

save device states and gate the clock.
The proposal, as I understand, is to use the pm hooks to actively
control the power states instead of using them as just notifications
of the SOC's power transitions. Considering this, we had one power
policy called "device_suspend_only". That is open to be broken down
into more device specific power states.

[HR] You are correct, we intend to use the pm driver hooks to
actively control the device Power states. We will use the Zephyer's
current power policies to indicate the system power state. As you
mentioned, when devices will not be in active state the system can still be at "device_suspend_only" state.
Do you see any issues with the apps/drivers keeping the PM service updated of the device's current state in real time? What about race conditions? Complexity of communication framework?
[HR] The need of communication framework and device state database lock may be needed. For example, inter processor communication may be needed if in a specific SoC
there are shared power resources between two cores (in AtP3 we may avoid that...)



The get_state function will enable the Power Manager service to know
the state

of each driver thus enable it to configure the SoC power behavior.
The set_state function looks ok. It is the same as the current
suspend but with the name change. The purpose of the name change is
to add a corresponding get_state. The RFC is not giving much details
of the use of the get_state function.

I assume there is a need for the PM service to build a device tree,
with power hierarchy. It would be helpful if you could explain how
this function fits in your larger design of the PM service's power
policy management of the devices.

[HR] I will give an example:
A user application decides to suspend the I2C and the SPI devices.
The application will then call the corresponding set_state functions of these devices.
The set_state functions will perform the store of the relevant device
state and gate the device clock. In the next idle time the _sys_soc_suspend will be called.
This will trigger the power manager service which will decide what
should be done to optimize the power (clock gate a branch or change the system power state.
The decision of the power manager service will be based on the
devices states which can be obtained also by using the get_state functions.

Since the PM service is expected to have communication established
with all components in the system, wouldn't it know what state each
device is set to? Querying each device and building a tree every time
there is an opportunity to suspend, may take some time causing delay in suspend.

[HR] You are correct, using the get_state function will lead to a
less optimal Power manager service and it will need to use a more optimized method.
However, it is a good practice to have this function as the
application may want to query the device state.

Second proposed change is to add the below device power states:

Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE

--------------------------------------------

Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE

-------------------------------------------------------

Device context is preserved by the HW and need not be restored by
the driver.

The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE

------------------------------------------------

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context
lost

by the hardware.

The device can be powered down.

The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE

---------------------------------------

Power has been fully removed from the device. The device context is
lost

when this state is entered, so the OS software will reinitialize the
device

when powering it back on.

Device may not wake itself as the SoC need to reinitialize the device.
The description of the power states here sounds like they are
notifications. It sounds like some other component is setting the
power state and notifies using these values and the drivers do
save/restore or other operations based on the notification. Are the
drivers expected to gate clocks, turn off peripherals etc. in these notifications?

[HR] These device power states serve two purposes:
1. The drivers are expected to perform all the power/clock changes It
can perform according to the selected power state and do not
influence other drivers.
2. The power manager service will use the drivers states to decide on
system power policy to go to (it can also stay in
SYS_PM_DEVICE_SUSPEND_ONLY but to optimize the clock gating scheme)
Would these become part of a specification that all device drivers would need to implement? In this scheme, the PM responsibilities are shared between PM Service, various apps and drivers. So some plan needs to be in place to ensure all of them cooperate as expected.
[HR] You are right, there is a need to define the PM responsibilities of the PM service, drivers and apps. However, this RFC was written to add the ability to support more than two device states, define the available states and to enable transition between them.
We will be happy to contribute also to define the above.


The initial part of the RFC does mention the application can set the
power state of the device and that is what the proposed set_state
function also suggests.

Do they serve both purposes? May be an example of how the device's
power state is actively changed and who and when does it, with
respect to these notifications, would help.

[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with DEVICE_PM_SUSPEND_STATE.
When idle comes the PM service is called and see that it can close the SPI and I2C PLL.
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.
Will the PM service also put devices to suspend state, or only the apps will do it? Looks like the PM Service will never enter Deep Sleep if any device is on - any exceptions?
[HR] Only apps will do that. The PM service can decide in some cases to go to deep sleep even if specific device is active (e.g. the device is located in the always on power domain). The decision to change power state is SoC specific.

In the above example, the system had to go to idle for the PLL to get turned off. If you had a central scheme to turn off clocks then the PLL could have been turned off when both i2c and spi got turned off. Just an observation.
[HR] There are indeed several ways to solve this and there will be a need to choose the best one for the specific SoC.

Comments/concerns welcome.

Thanks,

Hezi

--------------------------------------------------------------------
- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material
for the sole use of the intended recipient(s). Any review or
distribution by others is strictly prohibited. If you are not the
intended recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: [RFC] Power Management Infrastructure

D'alton, Alexandre <alexandre.dalton@...>
 

Hi,

Please find comments below.

Regards,
Alex.

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Thursday, July 14, 2016 9:32 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

On 7/13/2016 11:40 PM, Rahamim, Hezi wrote:
Hi Dimitriy,

The get_state is there only for symmetry and good practice.
As mentioned below the power manager service will probably not use it as it is
not efficient to do get_state to all devices to know all the devices states...
The more important part of the RFC is adding the set_state function and the
device policies.

That made me think why we originally came up with 2 functions when one was
enough. Probably we thought the same way - to keep symmetry. Problem is that
we will keep getting more needs and we will either add more functions to
device_pm_ops or will have to change existing ones.

Because, we agreed on the fact that suspend resume were managed by a central entity and was the only needed control over the drivers. I think this is still true.


[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with
DEVICE_PM_SUSPEND_STATE.
When idle comes the PM service is called and see that it can close the SPI and
I2C PLL.
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.
In my opinion the clock tree needs to be managed completely separately, and in a completely independent way of the pm state.
Each driver mark that they use their clock when active and mark that they do not need it when not active. One can consider that an enabled clock gate is equivalent to a deep sleep forbidden, but that won't be true always on clock gates.


Will the PM service also put devices to suspend state, or only the apps will do it?
Looks like the PM Service will never enter Deep Sleep if any device is on - any
exceptions?

In the above example, the system had to go to idle for the PLL to get turned off.
If you had a central scheme to turn off clocks then the PLL could have been
turned off when both i2c and spi got turned off. Just an observation.
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: [RFC] Power Management Infrastructure

Thomas, Ramesh
 

On 7/13/2016 11:40 PM, Rahamim, Hezi wrote:
Hi Dimitriy,

The get_state is there only for symmetry and good practice.
As mentioned below the power manager service will probably not use it as it is not efficient to do get_state to all devices to know all the devices states...
The more important part of the RFC is adding the set_state function and the device policies.
That made me think why we originally came up with 2 functions when one
was enough. Probably we thought the same way - to keep symmetry. Problem
is that we will keep getting more needs and we will either add more
functions to device_pm_ops or will have to change existing ones.

How about having one function that can be used for all possible device
PM purposes using a control code? Something like following :-

int device_pm_control(device, flags);

flags = (CONTROL_CODE | SYSTEM_POWER_STATE | DEVICE_POWER_STATE)

CONTROL_CODE = {SET_POWER_STATE, GET_POWER_STATE, ...}
DEVICE_POWER_STATE = {device PM states}
SYSTEM_POWER_STATE = {system power policies}

(We can add additional parameters if flags param is overloaded)

returns value based on CONTROL_CODE
e.g. returns device power state if CONTROL_CODE == GET_POWER_STATE

(We probably don't need device_pm_ops if we have only one function.)


***I also have some questions inline below***



Thanks for the comment,
Hezi

-----Original Message-----
From: Dmitriy Korovkin [mailto:dmitriy.korovkin(a)windriver.com]
Sent: Thursday, July 14, 2016 00:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: [RFC] Power Management Infrastructure

Hi Hezi,
I think RFC needs to be extended with the description of the idea of controlling power state of each device (if I got you correctly).
Without it the need of
int (*get_state)(struct device *device, int device_pm_policy); looks very unclear.
If all you need is to provide more that two states, then set_state() looks quite enough.

Regards,

Dmitriy Korovkin

On 16-07-13 12:11 PM, Rahamim, Hezi wrote:
Hi Ramesh,

Please see my comments below/

Thanks for the comments,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Wednesday, July 13, 2016 09:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Power Management Infrastructure

On 7/12/2016 2:03 AM, Rahamim, Hezi wrote:
Hi all,

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

between two driver states (suspend and resume). Drivers may have more
than two
Currently suspend and resume are not actually states but a notification of the state transition. There is a second argument to those functions that specify the current policy for which the transition is happening.


states (i.e. D-states) and can traverse between those states. The
state change

today is limited only from active to suspend while there can be cases
of other

transitions requested by the application.

Please look at the below suggested device power states E.g.
transition between

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an
application or

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

int (*suspend)(struct device *device, int pm_policy);

int (*resume)(struct device *device, int pm_policy);

};

Proposed changes

===============

First proposed change is to have a set state and get state driver
functions

instead of the suspend resume functions:

struct device_pm_ops {

int (*set_state)(struct device *device, int
device_pm_policy);

int (*get_state)(struct device *device, int
device_pm_policy);

};

The set_state function will behave according to the state transition
of a specific

driver. E.g. transition from active state to suspend state in a UART
device will

save device states and gate the clock.
The proposal, as I understand, is to use the pm hooks to actively
control the power states instead of using them as just notifications
of the SOC's power transitions. Considering this, we had one power
policy called "device_suspend_only". That is open to be broken down
into more device specific power states.

[HR] You are correct, we intend to use the pm driver hooks to actively
control the device Power states. We will use the Zephyer's current
power policies to indicate the system power state. As you mentioned,
when devices will not be in active state the system can still be at "device_suspend_only" state.
Do you see any issues with the apps/drivers keeping the PM service
updated of the device's current state in real time? What about race
conditions? Complexity of communication framework?



The get_state function will enable the Power Manager service to know
the state

of each driver thus enable it to configure the SoC power behavior.
The set_state function looks ok. It is the same as the current suspend
but with the name change. The purpose of the name change is to add a
corresponding get_state. The RFC is not giving much details of the
use of the get_state function.

I assume there is a need for the PM service to build a device tree,
with power hierarchy. It would be helpful if you could explain how
this function fits in your larger design of the PM service's power
policy management of the devices.

[HR] I will give an example:
A user application decides to suspend the I2C and the SPI devices. The
application will then call the corresponding set_state functions of these devices.
The set_state functions will perform the store of the relevant device
state and gate the device clock. In the next idle time the _sys_soc_suspend will be called.
This will trigger the power manager service which will decide what
should be done to optimize the power (clock gate a branch or change the system power state.
The decision of the power manager service will be based on the devices
states which can be obtained also by using the get_state functions.

Since the PM service is expected to have communication established
with all components in the system, wouldn't it know what state each
device is set to? Querying each device and building a tree every time
there is an opportunity to suspend, may take some time causing delay in suspend.

[HR] You are correct, using the get_state function will lead to a less
optimal Power manager service and it will need to use a more optimized method.
However, it is a good practice to have this function as the
application may want to query the device state.

Second proposed change is to add the below device power states:

Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE

--------------------------------------------

Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE

-------------------------------------------------------

Device context is preserved by the HW and need not be restored by the
driver.

The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE

------------------------------------------------

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context lost

by the hardware.

The device can be powered down.

The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE

---------------------------------------

Power has been fully removed from the device. The device context is
lost

when this state is entered, so the OS software will reinitialize the
device

when powering it back on.

Device may not wake itself as the SoC need to reinitialize the device.
The description of the power states here sounds like they are
notifications. It sounds like some other component is setting the
power state and notifies using these values and the drivers do
save/restore or other operations based on the notification. Are the
drivers expected to gate clocks, turn off peripherals etc. in these notifications?

[HR] These device power states serve two purposes:
1. The drivers are expected to perform all the power/clock changes It
can perform according to the selected power state and do not influence
other drivers.
2. The power manager service will use the drivers states to decide on
system power policy to go to (it can also stay in
SYS_PM_DEVICE_SUSPEND_ONLY but to optimize the clock gating scheme)
Would these become part of a specification that all device drivers would
need to implement? In this scheme, the PM responsibilities are shared
between PM Service, various apps and drivers. So some plan needs to be
in place to ensure all of them cooperate as expected.


The initial part of the RFC does mention the application can set the
power state of the device and that is what the proposed set_state
function also suggests.

Do they serve both purposes? May be an example of how the device's
power state is actively changed and who and when does it, with respect
to these notifications, would help.

[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with DEVICE_PM_SUSPEND_STATE.
When idle comes the PM service is called and see that it can close the SPI and I2C PLL.
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.
Will the PM service also put devices to suspend state, or only the apps
will do it? Looks like the PM Service will never enter Deep Sleep if any
device is on - any exceptions?

In the above example, the system had to go to idle for the PLL to get
turned off. If you had a central scheme to turn off clocks then the PLL
could have been turned off when both i2c and spi got turned off. Just an
observation.


Comments/concerns welcome.

Thanks,

Hezi

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: [RFC] Power Management Infrastructure

Rahamim, Hezi
 

Hi Dimitriy,

The get_state is there only for symmetry and good practice.
As mentioned below the power manager service will probably not use it as it is not efficient to do get_state to all devices to know all the devices states...
The more important part of the RFC is adding the set_state function and the device policies.

Thanks for the comment,
Hezi

-----Original Message-----
From: Dmitriy Korovkin [mailto:dmitriy.korovkin(a)windriver.com]
Sent: Thursday, July 14, 2016 00:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: [RFC] Power Management Infrastructure

Hi Hezi,
I think RFC needs to be extended with the description of the idea of controlling power state of each device (if I got you correctly).
Without it the need of
int (*get_state)(struct device *device, int device_pm_policy); looks very unclear.
If all you need is to provide more that two states, then set_state() looks quite enough.

Regards,

Dmitriy Korovkin

On 16-07-13 12:11 PM, Rahamim, Hezi wrote:
Hi Ramesh,

Please see my comments below/

Thanks for the comments,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Wednesday, July 13, 2016 09:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Power Management Infrastructure

On 7/12/2016 2:03 AM, Rahamim, Hezi wrote:
Hi all,

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

between two driver states (suspend and resume). Drivers may have more
than two
Currently suspend and resume are not actually states but a notification of the state transition. There is a second argument to those functions that specify the current policy for which the transition is happening.


states (i.e. D-states) and can traverse between those states. The
state change

today is limited only from active to suspend while there can be cases
of other

transitions requested by the application.

Please look at the below suggested device power states E.g.
transition between

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an
application or

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

int (*suspend)(struct device *device, int pm_policy);

int (*resume)(struct device *device, int pm_policy);

};

Proposed changes

===============

First proposed change is to have a set state and get state driver
functions

instead of the suspend resume functions:

struct device_pm_ops {

int (*set_state)(struct device *device, int
device_pm_policy);

int (*get_state)(struct device *device, int
device_pm_policy);

};

The set_state function will behave according to the state transition
of a specific

driver. E.g. transition from active state to suspend state in a UART
device will

save device states and gate the clock.
The proposal, as I understand, is to use the pm hooks to actively
control the power states instead of using them as just notifications
of the SOC's power transitions. Considering this, we had one power
policy called "device_suspend_only". That is open to be broken down
into more device specific power states.

[HR] You are correct, we intend to use the pm driver hooks to actively
control the device Power states. We will use the Zephyer's current
power policies to indicate the system power state. As you mentioned,
when devices will not be in active state the system can still be at "device_suspend_only" state.


The get_state function will enable the Power Manager service to know
the state

of each driver thus enable it to configure the SoC power behavior.
The set_state function looks ok. It is the same as the current suspend
but with the name change. The purpose of the name change is to add a
corresponding get_state. The RFC is not giving much details of the
use of the get_state function.

I assume there is a need for the PM service to build a device tree,
with power hierarchy. It would be helpful if you could explain how
this function fits in your larger design of the PM service's power
policy management of the devices.

[HR] I will give an example:
A user application decides to suspend the I2C and the SPI devices. The
application will then call the corresponding set_state functions of these devices.
The set_state functions will perform the store of the relevant device
state and gate the device clock. In the next idle time the _sys_soc_suspend will be called.
This will trigger the power manager service which will decide what
should be done to optimize the power (clock gate a branch or change the system power state.
The decision of the power manager service will be based on the devices
states which can be obtained also by using the get_state functions.

Since the PM service is expected to have communication established
with all components in the system, wouldn't it know what state each
device is set to? Querying each device and building a tree every time
there is an opportunity to suspend, may take some time causing delay in suspend.

[HR] You are correct, using the get_state function will lead to a less
optimal Power manager service and it will need to use a more optimized method.
However, it is a good practice to have this function as the
application may want to query the device state.

Second proposed change is to add the below device power states:

Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE

--------------------------------------------

Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE

-------------------------------------------------------

Device context is preserved by the HW and need not be restored by the
driver.

The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE

------------------------------------------------

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context lost

by the hardware.

The device can be powered down.

The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE

---------------------------------------

Power has been fully removed from the device. The device context is
lost

when this state is entered, so the OS software will reinitialize the
device

when powering it back on.

Device may not wake itself as the SoC need to reinitialize the device.
The description of the power states here sounds like they are
notifications. It sounds like some other component is setting the
power state and notifies using these values and the drivers do
save/restore or other operations based on the notification. Are the
drivers expected to gate clocks, turn off peripherals etc. in these notifications?

[HR] These device power states serve two purposes:
1. The drivers are expected to perform all the power/clock changes It
can perform according to the selected power state and do not influence
other drivers.
2. The power manager service will use the drivers states to decide on
system power policy to go to (it can also stay in
SYS_PM_DEVICE_SUSPEND_ONLY but to optimize the clock gating scheme)

The initial part of the RFC does mention the application can set the
power state of the device and that is what the proposed set_state
function also suggests.

Do they serve both purposes? May be an example of how the device's
power state is actively changed and who and when does it, with respect
to these notifications, would help.

[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with DEVICE_PM_SUSPEND_STATE.
When idle comes the PM service is called and see that it can close the SPI and I2C PLL.
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.


Comments/concerns welcome.

Thanks,

Hezi

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: [RFC] Power Management Infrastructure

Dmitriy Korovkin
 

Hi Hezi,
I think RFC needs to be extended with the description of the idea of
controlling power state of each device (if I got you correctly).
Without it the need of
int (*get_state)(struct device *device, int device_pm_policy);
looks very unclear.
If all you need is to provide more that two states, then set_state()
looks quite enough.

Regards,

Dmitriy Korovkin

On 16-07-13 12:11 PM, Rahamim, Hezi wrote:
Hi Ramesh,

Please see my comments below/

Thanks for the comments,
Hezi

-----Original Message-----
From: Thomas, Ramesh [mailto:ramesh.thomas(a)intel.com]
Sent: Wednesday, July 13, 2016 09:41
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Power Management Infrastructure

On 7/12/2016 2:03 AM, Rahamim, Hezi wrote:
Hi all,

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

between two driver states (suspend and resume). Drivers may have more
than two
Currently suspend and resume are not actually states but a notification of the state transition. There is a second argument to those functions that specify the current policy for which the transition is happening.


states (i.e. D-states) and can traverse between those states. The state
change

today is limited only from active to suspend while there can be cases of
other

transitions requested by the application.

Please look at the below suggested device power states E.g. transition
between

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an application or

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

int (*suspend)(struct device *device, int pm_policy);

int (*resume)(struct device *device, int pm_policy);

};

Proposed changes

===============

First proposed change is to have a set state and get state driver functions

instead of the suspend resume functions:

struct device_pm_ops {

int (*set_state)(struct device *device, int device_pm_policy);

int (*get_state)(struct device *device, int device_pm_policy);

};

The set_state function will behave according to the state transition of
a specific

driver. E.g. transition from active state to suspend state in a UART
device will

save device states and gate the clock.
The proposal, as I understand, is to use the pm hooks to actively
control the power states instead of using them as just notifications of
the SOC's power transitions. Considering this, we had one power policy
called "device_suspend_only". That is open to be broken down into more
device specific power states.

[HR] You are correct, we intend to use the pm driver hooks to actively control
the device Power states. We will use the Zephyer's current power policies to
indicate the system power state. As you mentioned, when devices will not be
in active state the system can still be at "device_suspend_only" state.


The get_state function will enable the Power Manager service to know the
state

of each driver thus enable it to configure the SoC power behavior.
The set_state function looks ok. It is the same as the current suspend
but with the name change. The purpose of the name change is to add a
corresponding get_state. The RFC is not giving much details of the use
of the get_state function.

I assume there is a need for the PM service to build a device tree, with
power hierarchy. It would be helpful if you could explain how this
function fits in your larger design of the PM service's power policy
management of the devices.

[HR] I will give an example:
A user application decides to suspend the I2C and the SPI devices. The application
will then call the corresponding set_state functions of these devices.
The set_state functions will perform the store of the relevant device state and
gate the device clock. In the next idle time the _sys_soc_suspend will be called.
This will trigger the power manager service which will decide what should be done
to optimize the power (clock gate a branch or change the system power state.
The decision of the power manager service will be based on the devices states
which can be obtained also by using the get_state functions.

Since the PM service is expected to have communication established with
all components in the system, wouldn't it know what state each device is
set to? Querying each device and building a tree every time there is an
opportunity to suspend, may take some time causing delay in suspend.

[HR] You are correct, using the get_state function will lead to a less optimal
Power manager service and it will need to use a more optimized method.
However, it is a good practice to have this function as the application
may want to query the device state.

Second proposed change is to add the below device power states:

Note: Many devices do not have all four power states defined.

DEVICE_PM_ACTIVE_STATE

--------------------------------------------

Normal operation of the device. All device context is retained.

DEVICE_PM_LOW_POWER_STATE

-------------------------------------------------------

Device context is preserved by the HW and need not be restored by the
driver.

The device do not allow the Power Manager service to power it down.

DEVICE_PM_SUSPEND_STATE

------------------------------------------------

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context lost

by the hardware.

The device can be powered down.

The device is allowing a wake signal to send them to active state.

DEVICE_PM_OFF_STATE

---------------------------------------

Power has been fully removed from the device. The device context is lost

when this state is entered, so the OS software will reinitialize the device

when powering it back on.

Device may not wake itself as the SoC need to reinitialize the device.
The description of the power states here sounds like they are
notifications. It sounds like some other component is setting the power
state and notifies using these values and the drivers do save/restore or
other operations based on the notification. Are the drivers expected to
gate clocks, turn off peripherals etc. in these notifications?

[HR] These device power states serve two purposes:
1. The drivers are expected to perform all the power/clock changes
It can perform according to the selected power state and do not influence
other drivers.
2. The power manager service will use the drivers states to decide on
system power policy to go to (it can also stay in SYS_PM_DEVICE_SUSPEND_ONLY
but to optimize the clock gating scheme)

The initial part of the RFC does mention the application can set the
power state of the device and that is what the proposed set_state
function also suggests.

Do they serve both purposes? May be an example of how the device's
power state is actively changed and who and when does it, with respect
to these notifications, would help.

[HR] Here is an example:
There are three peripherals in a certain SOC: UART, I2C and SPI.
Both I2C and SPI are fed from the same PLL and the UART from a second one.
At the beginning the three peripherals are at DEVICE_PM_ACTIVE_STATE.
The user application decides that the I2C and the SPI should go to suspend.
It then calls the set_state function of these devices with DEVICE_PM_SUSPEND_STATE.
When idle comes the PM service is called and see that it can close the SPI and I2C PLL.
However, it cannot move to SYS_PM_DEEP_SLEEP as the UART is still active.


Comments/concerns welcome.

Thanks,

Hezi

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

7081 - 7100 of 8104