Date   

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.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 3
[ZEP-546] UART interrupts not triggered on ARC
https://jira.zephyrproject.org/browse/ZEP-546

[ZEP-545] Wrong default value of CONFIG_ADC_QMSI_SAMPLE_WIDTH for x86 QMSI ADC
https://jira.zephyrproject.org/browse/ZEP-545

[ZEP-547] [nble] Failed to start encryption after reconnection
https://jira.zephyrproject.org/browse/ZEP-547


UPDATED JIRA items within last 24 hours: 2
[ZEP-522] TCP/client-mode: disconnect
https://jira.zephyrproject.org/browse/ZEP-522

[ZEP-537] doc: create external wiki page "Maintainers"
https://jira.zephyrproject.org/browse/ZEP-537


CLOSED JIRA items within last 24 hours: 1
[ZEP-476] (Won't Do) Enabling fragmentation reassembly causes compilation break
https://jira.zephyrproject.org/browse/ZEP-476


RESOLVED JIRA items within last 24 hours: 4
[ZEP-357] (Fixed) Support for the MAX44009 sensor
https://jira.zephyrproject.org/browse/ZEP-357

[ZEP-435] (Fixed) Ethernet/IPv4/TCP: ip_buf_appdatalen returns wrong values
https://jira.zephyrproject.org/browse/ZEP-435

[ZEP-477] (Won't Do) IPV6 reassembly of fragmented packets is not working
https://jira.zephyrproject.org/browse/ZEP-477

[ZEP-529] (Fixed) doc: add references to JIRA in ID creation page
https://jira.zephyrproject.org/browse/ZEP-529


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/3151 : net: yaip: Set the l2 src/dst addresses in nbuf
- https://gerrit.zephyrproject.org/r/3152 : net: yaip: Set the ll src and dst addresses in ethernet l2 driver
- https://gerrit.zephyrproject.org/r/3147 : net: yaip: Change how the L2 header space is reserved in net_buf
- https://gerrit.zephyrproject.org/r/3153 : net: yaip: Set IP protocol type when sending ethernet packet
- https://gerrit.zephyrproject.org/r/3149 : net: yaip: Re-send ARP when needed
- https://gerrit.zephyrproject.org/r/3160 : samples/usb: Fix build for usb_dfu example
- https://gerrit.zephyrproject.org/r/3129 : net: tests: Add unit tests for neighbor cache
- https://gerrit.zephyrproject.org/r/3145 : net: tests: Fix unit test for IP utils
- https://gerrit.zephyrproject.org/r/3148 : net: yaip: Add utility to remove ipv4 address from iface
- 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/3143 : net: yaip: Changed the IP and ll address debug prints
- https://gerrit.zephyrproject.org/r/3140 : net: yaip: Depending on debug flags the stdio.h is not included
- https://gerrit.zephyrproject.org/r/3122 : quark_se: Correct UART_IRQ_FLAGS to IOAPIC_LEVEL
- https://gerrit.zephyrproject.org/r/3142 : net: tests: Fix unit test for ARP
- https://gerrit.zephyrproject.org/r/3141 : net: yaip: Fix arp.h so that net_arp_init() is found
- https://gerrit.zephyrproject.org/r/3137 : net: yaip: Do not overwrite SYS_LOG_DOMAIN
- https://gerrit.zephyrproject.org/r/3139 : net: yaip: Print statistics using SYS_LOG
- 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/3158 : net: buf: Minor cleanups & fixes to the API documentation
- https://gerrit.zephyrproject.org/r/3128 : net: yaip: Add a neighbor cache needed in IPv6
- https://gerrit.zephyrproject.org/r/3135 : net: yaip: Use debugging net_buf unref function
- https://gerrit.zephyrproject.org/r/3134 : net: yaip: Process ICMPv6 packets only if IPv6 is enabled
- https://gerrit.zephyrproject.org/r/3133 : net: yaip: Refactor various network init functions
- https://gerrit.zephyrproject.org/r/3132 : net: yaip: Buffer leak if net_if_send_data() returns NET_DROP
- https://gerrit.zephyrproject.org/r/3131 : net: yaip: No need to do ARP for IPv6 network packet
- https://gerrit.zephyrproject.org/r/3130 : net: yaip: The IP protocol type needs to be set in L2 layer
- 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/3156 : slip: Fix the debug print
- https://gerrit.zephyrproject.org/r/3155 : net: yaip: Write ethernet header when using slip and tap
- https://gerrit.zephyrproject.org/r/3154 : net: yaip: Make sure ethernet l2 sets src and dst addresses
- https://gerrit.zephyrproject.org/r/3150 : net: yaip: Add ethernet address helpers
- https://gerrit.zephyrproject.org/r/3157 : Bluetooth: Fix changing advertising random address when scanning
- 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
- https://gerrit.zephyrproject.org/r/3123 : net: yaip: Add struct to store link layer address
- https://gerrit.zephyrproject.org/r/3114 : test: break doc

UPDATED within last 24 hours:
- 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/2876 : power_mgmt: Create arch/soc specific helper functions
- https://gerrit.zephyrproject.org/r/2566 : fs: [DO NOT MERGE] Add a sample app to demo file system
- 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/3067 : _loapic_isr_vector_get: fix implementation
- https://gerrit.zephyrproject.org/r/2915 : nios2: optionally print cause code reason
- https://gerrit.zephyrproject.org/r/2797 : sensor: add sensor_value_sprintf helper function
- https://gerrit.zephyrproject.org/r/3066 : quark_se: make EOI operations atomic
- https://gerrit.zephyrproject.org/r/2888 : doc: Update floating point docs for ARM
- https://gerrit.zephyrproject.org/r/2079 : Bluetooth: L2CAP: Introduce CoC channel states
- https://gerrit.zephyrproject.org/r/2996 : Bluetooth: L2CAP: Set BR/EDR CoC channel as connected
- https://gerrit.zephyrproject.org/r/2995 : Bluetooth: L2CAP: Mark finish CoC configuration on BR/EDR
- https://gerrit.zephyrproject.org/r/2327 : aon counter: Use locking mechanism to guard critical regions of API call
- https://gerrit.zephyrproject.org/r/2869 : power_mgmt: Add Deep Sleep support in sample PM app
- https://gerrit.zephyrproject.org/r/2868 : power_mgmt: Add device suspend/resume support to some core devices
- https://gerrit.zephyrproject.org/r/2565 : fs: [DO NOT MERGE] Add bottom layer disk io for FAT FS
- https://gerrit.zephyrproject.org/r/2903 : microkernel: Fix fifo buffer name generation in DEFINE_FIFO
- https://gerrit.zephyrproject.org/r/2871 : Bluetooth: Align the NBLE firmware version and upgrade SD
- 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/2994 : Bluetooth: L2CAP: Split security changed handler for BR/EDR
- https://gerrit.zephyrproject.org/r/3001 : i2c: Fixed i2c_dw spamming when logs are enabled
- https://gerrit.zephyrproject.org/r/2373 : testcases: stub for x86 core on Quark SE
- https://gerrit.zephyrproject.org/r/3005 : drivers/pinmux: Change spaces by tabs in the pinmap table
- https://gerrit.zephyrproject.org/r/2893 : Test: including second line with blank spaces and a tab.

MERGED within last 24 hours:
- 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/3121 : quark_d2000: Update UART_IRQ_FLAGS for the board
- 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/3109 : net: yaip: Save some bytes on net_if logic
- https://gerrit.zephyrproject.org/r/3110 : net: yaip: Add comment explaining net_core's verdict values
- https://gerrit.zephyrproject.org/r/3112 : net: yaip: Make sure that RX is started before TX
- https://gerrit.zephyrproject.org/r/3111 : net: yaip: Moved ARP helper macro to arp.h
- https://gerrit.zephyrproject.org/r/3118 : net: buf: Add complete net_buf_simple implementation
- https://gerrit.zephyrproject.org/r/3113 : net: yaip: Print available DATA buffers during nbuf alloc
- https://gerrit.zephyrproject.org/r/3068 : net: tests: Tweak the IP address test to use new net_if API
- https://gerrit.zephyrproject.org/r/3069 : net: yaip: Do not remove fragments if main buffer is not removed
- https://gerrit.zephyrproject.org/r/3070 : net: yaip: Add utility function returning IPv4 broadcast address
- https://gerrit.zephyrproject.org/r/3073 : net: yaip: Add utils to set IPv4 netmask and gateway in net_if
- 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/3077 : net: yaip: Added IPv4 ARP support
- https://gerrit.zephyrproject.org/r/3078 : net: tests: Unit tests for IPv4 ARP code
- 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/3081 : net: yaip: Only accept ARP reply if we requested data
- https://gerrit.zephyrproject.org/r/3082 : net: yaip: Make echo-server to use documentation IPv4 addresses
- 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/3088 : net: yaip: ICMPv4 checksum calculation fixed
- https://gerrit.zephyrproject.org/r/3089 : net: tests: Additional tests for ICMPv4 checksum verification
- https://gerrit.zephyrproject.org/r/3092 : net: yaip: Provide separate header file for ethernet
- https://gerrit.zephyrproject.org/r/3117 : net: buf: Introduce net_buf_simple object
- https://gerrit.zephyrproject.org/r/3115 : net: Add documentation about yielding
- https://gerrit.zephyrproject.org/r/3116 : net: buf: Group the data, size and len members at the end of net_buf
- https://gerrit.zephyrproject.org/r/3013 : x86: crt0: Fix '_sys_soc_resume' type declaration
- 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/3061 : net: Restructured Ethernet driver menu
- https://gerrit.zephyrproject.org/r/1871 : Bluetooth: Get the included service 128bit UUID
- https://gerrit.zephyrproject.org/r/3010 : doc: filter doc with repo script
- https://gerrit.zephyrproject.org/r/3060 : build: Update Bluetooth known_issues whitelist
- https://gerrit.zephyrproject.org/r/2949 : QMSI/uart: Use IOAPIC_EDGE instead of IOAPIC_LEVEL
- https://gerrit.zephyrproject.org/r/3063 : Bluetooth: Fix using NRPA for connectable advertising
- https://gerrit.zephyrproject.org/r/3002 : test_pool: exclude on olimexino_stm32 and nucleo_f103rb
- https://gerrit.zephyrproject.org/r/2948 : sensor: add driver for MAX44009 light sensor
- https://gerrit.zephyrproject.org/r/3024 : net: yaip: Drop received source mcast IPv6 packets
- https://gerrit.zephyrproject.org/r/3018 : net: yaip: Start to receive network packets
- https://gerrit.zephyrproject.org/r/3025 : net: yaip: Add extension header and bitmap fields to nbuf
- https://gerrit.zephyrproject.org/r/3026 : net: yaip: Add utility func to return IP address type as a string
- https://gerrit.zephyrproject.org/r/3027 : net: yaip: Add utility functions to check IPv6 addresses
- https://gerrit.zephyrproject.org/r/3019 : net: yaip: Add statistics gathering support
- https://gerrit.zephyrproject.org/r/3017 : net: yaip: Add net_context to compilation
- https://gerrit.zephyrproject.org/r/3020 : net: yaip: Add debug function to print MAC address
- https://gerrit.zephyrproject.org/r/3028 : net: yaip: Utilities to set and lookup interface IPv6 addresses
- https://gerrit.zephyrproject.org/r/3021 : net: yaip: Add debug function to print IP address
- https://gerrit.zephyrproject.org/r/3023 : net: yaip: Receive IPv6 packet
- https://gerrit.zephyrproject.org/r/3030 : net: yaip: Add IPv4 addresses to network interface
- https://gerrit.zephyrproject.org/r/3031 : net: tests: Add IPv4 address unit tests
- https://gerrit.zephyrproject.org/r/3022 : net: tests: Add unit test for IP and MAC address printing
- https://gerrit.zephyrproject.org/r/3029 : net: tests: Add IPv6 address manipulation unit tests
- https://gerrit.zephyrproject.org/r/3032 : net: yaip: IPv6 address utility funcs for network interface
- https://gerrit.zephyrproject.org/r/3040 : net: yaip: Network interface sets default IPv6 hop limit
- https://gerrit.zephyrproject.org/r/3042 : net: yaip: Add net_send_data() that sends data to network
- https://gerrit.zephyrproject.org/r/3043 : net: yaip: Network interface needs own TX fiber stack
- https://gerrit.zephyrproject.org/r/3045 : net: yaip: Add IP packet checksum calculation utilities
- https://gerrit.zephyrproject.org/r/3041 : net: yaip: Renamed network data receive function
- https://gerrit.zephyrproject.org/r/3033 : net: tests: Add more IPv6 address getters unit tests
- https://gerrit.zephyrproject.org/r/3035 : net: yaip: Receive IPv4 packet
- https://gerrit.zephyrproject.org/r/3034 : net: yaip: Network interface code compiles ok for IPv4 and IPv6
- https://gerrit.zephyrproject.org/r/3036 : net: yaip: Added API documentation to IP address check functions
- https://gerrit.zephyrproject.org/r/3037 : net: yaip: Fixed the IP/UDP/ICMP getter macros
- https://gerrit.zephyrproject.org/r/3039 : net: yaip: Move IP address print funcs to separate file
- https://gerrit.zephyrproject.org/r/3038 : net: yaip: Add ICMP protocol header struct
- https://gerrit.zephyrproject.org/r/3044 : net: yaip: Add net_hexdump() utility to print network data
- https://gerrit.zephyrproject.org/r/3046 : net: yaip: Add debugging option for network utilities
- https://gerrit.zephyrproject.org/r/3047 : net: tests: Unit tests for network utilities
- https://gerrit.zephyrproject.org/r/3048 : net: yaip: Add ICMPv6 handler
- https://gerrit.zephyrproject.org/r/3064 : net: Fix Kconfig warning
- https://gerrit.zephyrproject.org/r/3003 : nios2: get CPU features from ALT_CPU_* namespace
- https://gerrit.zephyrproject.org/r/3004 : altera_max10: support 'make flash' and 'make debug'
- https://gerrit.zephyrproject.org/r/3049 : net: yaip: Add unit tests for ICMPv6 handler
- https://gerrit.zephyrproject.org/r/2914 : nios2-qemu: correct system.h
- https://gerrit.zephyrproject.org/r/3050 : net: yaip: Process received ICMPv6 messages
- https://gerrit.zephyrproject.org/r/3051 : net: yaip: Process received ICMPv4 messages
- https://gerrit.zephyrproject.org/r/3052 : net: yaip: Add utility function to return default network interface
- https://gerrit.zephyrproject.org/r/2911 : altera_max10: cleanup defconfig
- https://gerrit.zephyrproject.org/r/2912 : nios2: enable XIP by default
- https://gerrit.zephyrproject.org/r/2913 : qemu_nios2: remove debug options from defconfig


Re: [RFC] Power Management Infrastructure

Rahamim, Hezi
 

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.


Re: [RFC] Zephyr Shell Enhancement

Tomasz Bursztyka
 

Hi Yael,

Clear RFC.

I have tiny inputs below

Shell service (shell_service.c)

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

• Add a new file: kernel/nanokernel/shell_service.c

• Responsibility: Initializes shell and add framework usage of the shell.

• Note: Memory for a specific module shell usage is not allocated if shell

is disabled in framework level, even if it is enabled in module’s level.

#define SHELL_PROMPT "shell> "

#define SHELL_FW "FW"

struct shell_cmd fw_commands[] = {

{ "sample", shell_cmd_sample, "help sample info" },

{ NULL, NULL }
As you know the size of fw_commands (which can be declared as const
btw) at built time,
you will be able to loop directly on that count, thus you could remove
this last entry.

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

Memory consumption

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

File: include/misc/shell.h

This file is the shell header file.

The following code already exists in its current Zephyr version:

typedef int (*shell_cmd_function_t)(int argc, char *argv[]);

struct shell_cmd {

const char *cmd_name;

shell_cmd_function_t cb;

const char *help;

};

• Note: Currently, “help” string’s length is not limited.

However, limitation on the length of each command’s help string
should be

added.
And supporting such help could be Kconfig based.
You may want to build the commands without their help string.

Shell Section

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

1. Architecture dependency:

For all supported architectures – appropriate section prolog should be

declared.

Example- X86 arch:

File: include/arch/x86/linker-common-sections.h

SECTION_PROLOGUE(initshell, (OPTIONAL),)

{

SHELL_INIT_SECTIONS()

KEXEC_PGALIGN_PAD(MMU_PAGE_SIZE)

} GROUP_LINK_IN(RAM)
I don't see any blocker not to put it in romable region or?

===========

Open issues

===========

• Improve search:

Search (of the entity and then of the command) can be improved, for

example, by using hash tables.

This improvement has a conflict between Performance issue and Memory

consumption.

The improvement may be different between nanokernel and microkernel.

This improvement is currently out of this proposal scope.
Indeed there would be a lot to try here, from a very basic alphabet
index to an hash table
or search tree etc...

Tomasz


[RFC] Zephyr Shell Enhancement

Avramovich, Yael <yael.avramovich@...>
 

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.

=============
Dynamic usage
=============

Infrastructure level:
-------------------------
File: misc/Kconfig

menu "Debugging Options"
......

config ENABLE_FW_SHELL
bool
prompt "Enable Shell service"
default y
help
Enabling shell services. If it is enabled, framework shell commands are
also available for use.


Module level:
------------------
Each module that wants to use shell service will add an appropriate config in
its kConfig file.
Example:
CONFIG_SAMPLE_MODULE_USE_SHELL=y
In the module's code, the shell usage is depend on the config parameter
(will be explained later on in the document).


===============================
FW shell service initialization
===============================
* Add a new call in _main() to "run_services".
* Kernel services:
Shell service initialization is done as part of a new module in kernel,
which is called - "kernel services".
This module initiates all kernel services.
Its functionality may be divided later on between microkernel and
nanokernel.
* Kernel services initialization is done before run main task
(nanokernel - background task, microkernel - idle task).
* Shell service initialization includes also adding basic framework
commands to shell commands.

Nanokernel initialization (nano_init.c)
----------------------------------------------
extern void run_services(void);
static void _main(void)
{
........
run_services();
extern void main(void);
main();
}

Microkernel initialization (k_init.c)
------------------------------------------
void _main(void)
{
...
task_group_start(EXE_GROUP);
run_services();
_k_kernel_idle();
}

Kernel services (kernel_services.c)
------------------------------------------
* Add a new file: kernel/nanokernel/kernel_services.c
* Responsibility: Initializing each kernel service, according to
configuration file.
* Kernel service definition: A module that should run after kernel and
devices initialization phase but before running main task.

Example to running kernel service:

extern void run_shell_service(void);

void run_services(void)
{
#ifdef CONFIG_ENABLE_FW_SHELL
run_shell_service();
#endif
}

The exact way of running kernel services will be redefined later.


Shell service (shell_service.c)
------------------------------------
* Add a new file: kernel/nanokernel/shell_service.c
* Responsibility: Initializes shell and add framework usage of the shell.
* Note: Memory for a specific module shell usage is not allocated if shell
is disabled in framework level, even if it is enabled in module's level.

#define SHELL_PROMPT "shell> "
#define SHELL_FW "FW"

struct shell_cmd fw_commands[] = {
{ "sample", shell_cmd_sample, "help sample info" },
{ NULL, NULL }
};

void run_shell_service(void)
{
shell_init(SHELL_PROMPT);
REGISTER_TO_SHELL(SHELL_FW, fw_commands);
}

====================
Module dynamic usage
====================
Each entity that wants to get shell services, should add its shell
identifier (as string) and register its call backs in shell database.

Example:
samples/shell/src/main.c
Put your code in main() or in another function, if the module is not an
exe task.

#define MY_SHELL_ENTITY "my_module"

struct shell_cmd commands[] = {
{ "ping", shell_cmd_ping, "print pong" },
{ "ticks", shell_cmd_ticks },
{ "highticks", shell_cmd_highticks },
{ NULL, NULL }
};

void main(void)
{
.....

#ifdef CONFIG_SAMPLE_MODULE_USE_SHELL
REGISTER_TO_SHELL(MY_SHELL_ENTITY, commands);
#endif
}

===================
Memory consumption
===================
File: include/misc/shell.h
This file is the shell header file.
The following code already exists in its current Zephyr version:
typedef int (*shell_cmd_function_t)(int argc, char *argv[]);

struct shell_cmd {
const char *cmd_name;
shell_cmd_function_t cb;
const char *help;
};

* Note: Currently, "help" string's length is not limited.
However, limitation on the length of each command's help string should be
added.

Shell initialization
-----------------------
File: include/misc/shell.h
* Current code:
/** init shell fiber and the shell commands.*/
void shell_init(const char *prompt, const struct shell_cmd *cmds);

* Suggested code:
/** Init shell fiber and register serial console handler. Commands are
initialized seperately*/
void shell_init(const char *prompt);

struct shell_entity {
const char *entity_name;
struct shell_cmd *commands;
};

#ifdef CONFIG_ENABLE_FW_SHELL
#define REGISTER_TO_SHELL(shell_name, shell_commands) \
\
static struct shell_entity (__shell_shell_name) __used \
__attribute__((__section__(".shell_"))) = { \
.entity_name = shell_name, \
.commands = shell_commands \
}

#else
#define REGISTER_TO_SHELL(shell_name, shell_commands)
#endif

Explanation:
- The shell entities and their commands need to be stored in a dedicated
code section whose boundaries are identified by its start and end
addresses.
- Memory for shell usage is not allocated if shell is disabled in
framework level, even if it is enabled in module level.

Shell Section
-----------------
1. Architecture dependency:
For all supported architectures - appropriate section prolog should be
declared.
Example- X86 arch:
File: include/arch/x86/linker-common-sections.h
SECTION_PROLOGUE(initshell, (OPTIONAL),)
{
SHELL_INIT_SECTIONS()
KEXEC_PGALIGN_PAD(MMU_PAGE_SIZE)
} GROUP_LINK_IN(RAM)

2. Architecture independence:
Identical for all architectures - shell section implementation:
File: include/linker-defs.h
#define SHELL_INIT_SECTIONS() \
__shell_cmd_start = .; \
KEEP(*(".shell_*")); \
__shell_cmd_end = .;

3. Section usage in code:
File: drivers/console/console_handler_shell.c
This file is the console handler implementation of shell.h API
* Current code:
static const struct shell_cmd *commands;
Each access to the commands array is done via commands array.

* Suggested code:
extern struct shell_entity __shell_cmd_start[];
extern struct shell_entity __shell_cmd_end[];
#define NUM_OF_SHELL_ENTITIES (__shell_cmd_end - __shell_cmd_start)
Each access to the commands array should be done via
__shell_cmd_start[entity].

============
Shell format
============
Specific command:
------------------------
* ENTITY COMMAND

Help commands:
---------------------
* help
Prints the string of all the entities.
* help ENTITY
Prints the available commands' names for the entity.
* help ENTITY COMMAND
Prints the help for the command of the entity (Depends on programmer
- the help should show function goal and required parameters).

=============================
Finding the correct call back
=============================
How do the shell service find the appropriate entity and command?
* Current implementation:
Search the string in commands array (strcmp)

* Suggested implementation:
First - search the entity.
Then - search the string in the specific's entity commands array.
The search is done by strcmp.

Note:
Relevant help is shown in case the search has failed.

======
Notes
======

* Non - preemption:
Due to the non-preemptive nature of the nanokernel's scheduler, a fiber
that performs lengthy computations may cause an unacceptable delay in the
scheduling of other fibers, including higher priority and equal priority
ones.
Therefore, shell callbacks should be short as possible.

* Shell fiber priority:
Should be the lowest among all fibers.
Currently it's not the lowest. For example, workqueue fibers has lower
priority. This should be changed.

===========
Open issues
===========
* Improve search:
Search (of the entity and then of the command) can be improved, for
example, by using hash tables.
This improvement has a conflict between Performance issue and Memory
consumption.
The improvement may be different between nanokernel and microkernel.
This improvement is currently out of this proposal scope.

---------------------------------------------------------------------
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 Alex,

Please see my comments below.

Thank you for the inputs,
Hezi

From: D'alton, Alexandre
Sent: Tuesday, July 12, 2016 17:31
To: Rahamim, Hezi <hezi.rahamim(a)intel.com>; devel(a)lists.zephyrproject.org
Cc: Kidron, Amihai <amihai.kidron(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>
Subject: RE: [RFC] Power Management Infrastructure

Hi Hezi,

Is there a specific need of being able to retrieve the current state of a device ?
It would only make sense if the device were able to change state by itself, which as far as I can tell is not the case.
Currently, the devices are slaves of the PM policy implementation and execute the state transitions accordingly.

[HR] We intend to give the user application the ability to set the state of the device according to its need.
The power manager service will then be called using the _sys_soc_suspend hook.
The power manager service will try to see if there is option to change the system state or to optimize the clock/power domain for the current devices states.

For the clock gating options, each drivers should transparently manage their clock gating in order to ensure an efficient power consumption i.e.:
While there is a spi transfer pending, keep the clock for the spi module and as soon as no spi transfer pending, disable its clock.

If you then implement a 'clock tree' driver whose interface is used by all drivers, then you can safely disable whole branches when the resource are not needed.
[HR] You are correct, when _sys_soc_suspend is called the power manager service will try to disable whole branches when the resource is not needed.

Regards,
Alex.

From: Rahamim, Hezi [mailto:hezi.rahamim(a)intel.com]
Sent: Tuesday, July 12, 2016 11:03 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Cc: Kidron, Amihai <amihai.kidron(a)intel.com<mailto:amihai.kidron(a)intel.com>>; Siman-tov, Keren <keren.siman-tov(a)intel.com<mailto:keren.siman-tov(a)intel.com>>
Subject: [devel] [RFC] Power Management Infrastructure

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

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


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.

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.

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?

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.

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.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-541] Integrate QMSI releases to Zephyr
https://jira.zephyrproject.org/browse/ZEP-541

[ZEP-544] Web site search on /doc pages returns no results
https://jira.zephyrproject.org/browse/ZEP-544


UPDATED JIRA items within last 24 hours: 5
[ZEP-228] File system interface designed after POSIX
https://jira.zephyrproject.org/browse/ZEP-228

[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-415] aaU, I want to use the NATS messaging protocol to send sensor data to the cloud
https://jira.zephyrproject.org/browse/ZEP-415

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


CLOSED JIRA items within last 24 hours: 1
[ZEP-398] (Fixed) i2c FRAM sample not working
https://jira.zephyrproject.org/browse/ZEP-398


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-243] (Fixed) Create Wiki Structure for Boards
https://jira.zephyrproject.org/browse/ZEP-243

[ZEP-272] (Fixed) nios2: add global pointer support
https://jira.zephyrproject.org/browse/ZEP-272


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/3041 : net: yaip: Renamed network data receive function
- https://gerrit.zephyrproject.org/r/3049 : net: yaip: Add unit tests for ICMPv6 handler
- https://gerrit.zephyrproject.org/r/3047 : net: tests: Unit tests for network utilities
- https://gerrit.zephyrproject.org/r/3046 : net: yaip: Add debugging option for network utilities
- https://gerrit.zephyrproject.org/r/3045 : net: yaip: Add IP packet checksum calculation utilities
- https://gerrit.zephyrproject.org/r/3043 : net: yaip: Network interface needs own TX fiber stack
- https://gerrit.zephyrproject.org/r/3062 : Bluetooth: ATT: Fix using non-ASCII characters
- https://gerrit.zephyrproject.org/r/3029 : net: tests: Add IPv6 address manipulation unit tests
- https://gerrit.zephyrproject.org/r/3035 : net: yaip: Receive IPv4 packet
- https://gerrit.zephyrproject.org/r/3019 : net: yaip: Add statistics gathering support
- https://gerrit.zephyrproject.org/r/3061 : net: Moved Ethernet driver debug level setting to networking
- https://gerrit.zephyrproject.org/r/3020 : net: yaip: Add debug function to print MAC address
- https://gerrit.zephyrproject.org/r/3048 : net: yaip: Add ICMPv6 handler
- https://gerrit.zephyrproject.org/r/3044 : net: yaip: Add net_hexdump() utility to print network data
- https://gerrit.zephyrproject.org/r/3026 : net: yaip: Add utility func to return IP address type as a string
- https://gerrit.zephyrproject.org/r/3051 : net: yaip: Process received ICMPv4 messages
- https://gerrit.zephyrproject.org/r/3034 : net: yaip: Network interface code compiles ok for IPv4 and IPv6
- https://gerrit.zephyrproject.org/r/3039 : net: yaip: Move IP address print funcs to separate file
- https://gerrit.zephyrproject.org/r/3018 : net: yaip: Start to receive network packets
- https://gerrit.zephyrproject.org/r/3038 : net: yaip: Add ICMP protocol header struct
- https://gerrit.zephyrproject.org/r/3040 : net: yaip: Network interface sets default IPv6 hop limit
- https://gerrit.zephyrproject.org/r/3037 : net: yaip: Fixed the IP/UDP/ICMP getter macros
- https://gerrit.zephyrproject.org/r/3021 : net: yaip: Add debug function to print IP address
- https://gerrit.zephyrproject.org/r/3036 : net: yaip: Added API documentation to IP address check functions
- https://gerrit.zephyrproject.org/r/3031 : net: tests: Add IPv4 address unit tests
- https://gerrit.zephyrproject.org/r/3027 : net: yaip: Add utility functions to check IPv6 addresses
- https://gerrit.zephyrproject.org/r/3023 : net: yaip: Receive IPv6 packet
- https://gerrit.zephyrproject.org/r/3024 : net: yaip: Drop received source mcast IPv6 packets
- https://gerrit.zephyrproject.org/r/3017 : net: yaip: Add net_context to compilation
- https://gerrit.zephyrproject.org/r/3022 : net: tests: Add unit test for IP and MAC address printing
- https://gerrit.zephyrproject.org/r/3028 : net: yaip: Utilities to set and lookup interface IPv6 addresses
- https://gerrit.zephyrproject.org/r/3030 : net: yaip: Add IPv4 addresses to network interface
- https://gerrit.zephyrproject.org/r/3032 : net: yaip: IPv6 address utility funcs for network interface
- https://gerrit.zephyrproject.org/r/3052 : net: yaip: Add utility function to return default network interface
- https://gerrit.zephyrproject.org/r/3050 : net: yaip: Process received ICMPv6 messages
- https://gerrit.zephyrproject.org/r/3042 : net: yaip: Add net_send_data() that sends data to network
- https://gerrit.zephyrproject.org/r/3033 : net: tests: Add more IPv6 address getters unit tests
- https://gerrit.zephyrproject.org/r/3025 : net: yaip: Add extension header and bitmap fields to nbuf
- https://gerrit.zephyrproject.org/r/3060 : build: Update Bluetooth known_issues whitelist
- https://gerrit.zephyrproject.org/r/3055 : drivers/nble: Decrease number of interrupts needed to read packet
- https://gerrit.zephyrproject.org/r/3054 : Bluetooth/shell: Add uart-test command for nble testing
- https://gerrit.zephyrproject.org/r/3056 : drivers/nble: Add UART error checks for debug
- https://gerrit.zephyrproject.org/r/3053 : drivers/nble: Improve debug
- https://gerrit.zephyrproject.org/r/3005 : drivers/pinmux: Change spaces by tabs in the pinmap table
- https://gerrit.zephyrproject.org/r/3013 : x86: crt0: Fix '_sys_soc_resume' type declaration
- https://gerrit.zephyrproject.org/r/3010 : doc: filter doc with repo script
- https://gerrit.zephyrproject.org/r/3015 : x86: crt0: Remove 'je copyDataDone' from CONFIG_XIP block
- https://gerrit.zephyrproject.org/r/3014 : samples: Add Quark SE power management application
- https://gerrit.zephyrproject.org/r/3016 : samples: power/quark_se: Add support for Sleep states
- https://gerrit.zephyrproject.org/r/3012 : samples: Add suspend/resume of devices to Quark SE power sample
- https://gerrit.zephyrproject.org/r/3003 : nios2: get CPU features from ALT_CPU_* namespace
- https://gerrit.zephyrproject.org/r/3004 : altera_max10: support 'make flash' and 'make debug'
- https://gerrit.zephyrproject.org/r/3002 : test_pool: exclude on olimexino_stm32 and nucleo_f103rb
- https://gerrit.zephyrproject.org/r/3001 : i2c: Fixed i2c_dw spamming when logs are enabled

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/2888 : doc: Update floating point docs for ARM
- https://gerrit.zephyrproject.org/r/2953 : x86: merge IAMCU and SYS V core arch code
- https://gerrit.zephyrproject.org/r/2079 : Bluetooth: L2CAP: Introduce CoC channel states
- https://gerrit.zephyrproject.org/r/1871 : Bluetooth: Get the included service 128bit UUID
- https://gerrit.zephyrproject.org/r/2949 : QMSI/uart: Use IOAPIC_EDGE instead of IOAPIC_LEVEL
- https://gerrit.zephyrproject.org/r/2868 : power_mgmt: Add device suspend/resume support to some core devices
- https://gerrit.zephyrproject.org/r/2871 : Bluetooth: Align the NBLE firmware version and upgrade SD
- https://gerrit.zephyrproject.org/r/2876 : power_mgmt: Create arch/soc specific helper functions
- https://gerrit.zephyrproject.org/r/2869 : power_mgmt: Add Deep Sleep support in sample PM app
- https://gerrit.zephyrproject.org/r/2919 : ext qmsi: Build the power states support from QMSI
- https://gerrit.zephyrproject.org/r/2918 : ext qmsi: Make QMSI headers available to more than just drivers
- https://gerrit.zephyrproject.org/r/2914 : nios2-qemu: correct system.h
- https://gerrit.zephyrproject.org/r/2912 : nios2: enable XIP by default
- https://gerrit.zephyrproject.org/r/2911 : altera_max10: cleanup defconfig
- https://gerrit.zephyrproject.org/r/2913 : qemu_nios2: remove debug options from defconfig
- https://gerrit.zephyrproject.org/r/2994 : Bluetooth: L2CAP: Split security changed handler for BR/EDR
- https://gerrit.zephyrproject.org/r/2998 : Bluetooth: L2CAP: Handle BR/EDR configuration deferred by GAP
- https://gerrit.zephyrproject.org/r/2995 : Bluetooth: L2CAP: Mark finish of BR/EDR configuration
- https://gerrit.zephyrproject.org/r/2997 : Bluetooth: L2CAP: Introduce security requirements
- https://gerrit.zephyrproject.org/r/2996 : Bluetooth: L2CAP: Flag BR/EDR channel as connected
- https://gerrit.zephyrproject.org/r/2895 : nanokernel: modifying nanokernel to remove duplicate symbols in image file

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/3059 : net: buf: Add basic documentation for net_buf struct
- https://gerrit.zephyrproject.org/r/3058 : net: buf: Fix documentation of fragment related API
- https://gerrit.zephyrproject.org/r/3057 : net: tests: Temporarily remove nbuf unit test
- https://gerrit.zephyrproject.org/r/2880 : net: Yield before sending packets
- https://gerrit.zephyrproject.org/r/2809 : net: Update ip_buf_len for TCP packets
- https://gerrit.zephyrproject.org/r/2971 : net: Add generic network interface header
- https://gerrit.zephyrproject.org/r/2980 : net: yaip: Compile IPv6 and IPv4 address conditionally
- https://gerrit.zephyrproject.org/r/2977 : net: yaip: Add TX fifo to network interface
- https://gerrit.zephyrproject.org/r/2979 : net: yaip: Add function that feeds data to RX fifo
- https://gerrit.zephyrproject.org/r/2975 : net: yaip: Add IPv6 prefixes to network interface
- https://gerrit.zephyrproject.org/r/2978 : net: yaip: Refactored RX fiber init
- https://gerrit.zephyrproject.org/r/2970 : net: Add header file for generic link address
- https://gerrit.zephyrproject.org/r/2984 : net: yaip: Add net_analyze_stack() macro
- https://gerrit.zephyrproject.org/r/2989 : net: yaip: Add Kconfig option for compiling IPv4 support
- https://gerrit.zephyrproject.org/r/2976 : net: yaip: Let new IP stack know the debug Kconfig options
- https://gerrit.zephyrproject.org/r/2983 : net: yaip: Fix compilation error in net_if.h
- https://gerrit.zephyrproject.org/r/2985 : net: Show only uIP debug options when needed
- https://gerrit.zephyrproject.org/r/2986 : net: yaip: Add Kconfig option for compiling IPv6 support
- https://gerrit.zephyrproject.org/r/2987 : net: yaip: Execute net_init() automatically
- https://gerrit.zephyrproject.org/r/2988 : net: yaip: Add net_if_get_by_link_addr() util function
- https://gerrit.zephyrproject.org/r/2974 : net: yaip: Add multicast address to network interface
- https://gerrit.zephyrproject.org/r/2990 : net: yaip: Add send() to net_if API
- https://gerrit.zephyrproject.org/r/2968 : net: yaip: Use same prefix in new IP stack Kconfig
- https://gerrit.zephyrproject.org/r/2991 : net: yaip: Start to use logging macros from sys_log.h
- https://gerrit.zephyrproject.org/r/2993 : net: yaip: Enable compilation of net_if.c
- https://gerrit.zephyrproject.org/r/2992 : net: yaip: Refactor debug printing in net_if
- https://gerrit.zephyrproject.org/r/2972 : net: yaip: apps: Create a skeleton echo-server for new IP stack
- https://gerrit.zephyrproject.org/r/2981 : net: yaip: Add nbuf buffer API
- https://gerrit.zephyrproject.org/r/2982 : slip: Add driver for host to qemu connectivity
- https://gerrit.zephyrproject.org/r/2973 : net: yaip: Add network address information to interface
- https://gerrit.zephyrproject.org/r/2969 : net: yaip: Compile new stack if enabled
- https://gerrit.zephyrproject.org/r/2965 : net: yaip: Initial commit for new IP stack
- https://gerrit.zephyrproject.org/r/2966 : net: yaip: Add defines for various IP protocol header lengths
- https://gerrit.zephyrproject.org/r/2967 : net: yaip: Add ntohl() and related macros
- https://gerrit.zephyrproject.org/r/2731 : _nios2_read_sp: fix register read
- https://gerrit.zephyrproject.org/r/2693 : Bluetooth: L2CAP: Start servicing configuration request from remote
- https://gerrit.zephyrproject.org/r/2964 : net: buf: Calculate amount of bytes in fragments
- https://gerrit.zephyrproject.org/r/1815 : net: buf: Add tests for net_buf fragmentation
- https://gerrit.zephyrproject.org/r/1649 : net: buf: Add fragmentation API tests
- https://gerrit.zephyrproject.org/r/2954 : Revert "REVERTME: test_pool disable due to memory corruption bug"
- https://gerrit.zephyrproject.org/r/3000 : Bluetooth: L2CAP: Fix not canceling RTX work
- https://gerrit.zephyrproject.org/r/2999 : Bluetooth: L2CAP: Unify code for adding and deleting channels
- https://gerrit.zephyrproject.org/r/2950 : Bluetooth: L2CAP: Make l2cap_chan_add initialize the destroy callback
- https://gerrit.zephyrproject.org/r/2963 : net: buf: Add fragmentation API support


Re: [RFC] Power Management Infrastructure

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

Hi Hezi,

Is there a specific need of being able to retrieve the current state of a device ?
It would only make sense if the device were able to change state by itself, which as far as I can tell is not the case.
Currently, the devices are slaves of the PM policy implementation and execute the state transitions accordingly.

For the clock gating options, each drivers should transparently manage their clock gating in order to ensure an efficient power consumption i.e.:
While there is a spi transfer pending, keep the clock for the spi module and as soon as no spi transfer pending, disable its clock.

If you then implement a 'clock tree' driver whose interface is used by all drivers, then you can safely disable whole branches when the resource are not needed.

Regards,
Alex.

From: Rahamim, Hezi [mailto:hezi.rahamim(a)intel.com]
Sent: Tuesday, July 12, 2016 11:03 AM
To: devel(a)lists.zephyrproject.org
Cc: Kidron, Amihai <amihai.kidron(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>
Subject: [devel] [RFC] Power Management Infrastructure

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

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


[RFC] Power Management Infrastructure

Rahamim, Hezi
 

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

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.

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.


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/2990 : net: yaip: Add send() to net_if API
- https://gerrit.zephyrproject.org/r/2986 : net: yaip: Add Kconfig option for compiling IPv6 support
- https://gerrit.zephyrproject.org/r/2991 : net: yaip: Start to use logging macros from sys_log.h
- https://gerrit.zephyrproject.org/r/2985 : net: Show only uIP debug options when needed
- https://gerrit.zephyrproject.org/r/2989 : net: yaip: Add Kconfig option for compiling IPv4 support
- https://gerrit.zephyrproject.org/r/2987 : net: yaip: Execute net_init() automatically
- https://gerrit.zephyrproject.org/r/2983 : net: yaip: Fix compilation error in net_if.h
- https://gerrit.zephyrproject.org/r/2984 : net: yaip: Add net_analyze_stack() macro
- https://gerrit.zephyrproject.org/r/2982 : slip: Add driver for host to qemu connectivity
- https://gerrit.zephyrproject.org/r/2981 : net: yaip: Add nbuf buffer API
- https://gerrit.zephyrproject.org/r/2979 : net: yaip: Add function that feeds data to RX fifo
- https://gerrit.zephyrproject.org/r/3000 : Bluetooth: L2CAP: Fix not canceling RTX work
- https://gerrit.zephyrproject.org/r/2978 : net: yaip: Refactored RX fiber init
- https://gerrit.zephyrproject.org/r/2977 : net: yaip: Add TX fifo to network interface
- https://gerrit.zephyrproject.org/r/2999 : Bluetooth: L2CAP: Unify code for adding and deleting channels
- https://gerrit.zephyrproject.org/r/2975 : net: yaip: Add IPv6 prefixes to network interface
- https://gerrit.zephyrproject.org/r/2974 : net: yaip: Add multicast address to network interface
- https://gerrit.zephyrproject.org/r/2973 : net: yaip: Add network address information to interface
- https://gerrit.zephyrproject.org/r/2972 : net: yaip: apps: Create a skeleton echo-server for new IP stack
- https://gerrit.zephyrproject.org/r/2971 : net: Add generic network interface header
- https://gerrit.zephyrproject.org/r/2970 : net: Add header file for generic link address
- https://gerrit.zephyrproject.org/r/2966 : net: yaip: Add defines for various IP protocol header lengths
- https://gerrit.zephyrproject.org/r/2965 : net: yaip: Initial commit for new IP stack
- https://gerrit.zephyrproject.org/r/2993 : net: yaip: Enable compilation of net_if.c
- https://gerrit.zephyrproject.org/r/2992 : net: yaip: Refactor debug printing in net_if
- https://gerrit.zephyrproject.org/r/2988 : net: yaip: Add net_if_get_by_link_addr() util function
- https://gerrit.zephyrproject.org/r/2980 : net: yaip: Compile IPv6 and IPv4 address conditionally
- https://gerrit.zephyrproject.org/r/2976 : net: yaip: Let new IP stack know the debug Kconfig options
- https://gerrit.zephyrproject.org/r/2969 : net: yaip: Compile new stack if enabled
- https://gerrit.zephyrproject.org/r/2968 : net: yaip: Use same prefix in new IP stack Kconfig
- https://gerrit.zephyrproject.org/r/2967 : net: yaip: Add ntohl() and related macros
- https://gerrit.zephyrproject.org/r/2964 : net: buf: Calculate amount of bytes in fragments
- 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
- https://gerrit.zephyrproject.org/r/2996 : Bluetooth: L2CAP: Flag BR/EDR channel as connected
- https://gerrit.zephyrproject.org/r/2995 : Bluetooth: L2CAP: Mark finish of BR/EDR configuration
- https://gerrit.zephyrproject.org/r/2994 : Bluetooth: L2CAP: Split security changed handler for BR/EDR

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1815 : net: buf: Add tests for net_buf fragmentation
- https://gerrit.zephyrproject.org/r/2888 : doc: Update floating point docs for ARM
- https://gerrit.zephyrproject.org/r/1649 : net: buf: Add fragmentation API tests
- https://gerrit.zephyrproject.org/r/1871 : Bluetooth: Get the included service 128bit UUID
- https://gerrit.zephyrproject.org/r/2871 : Bluetooth: Align the NBLE firmware version and upgrade SD
- https://gerrit.zephyrproject.org/r/2693 : Bluetooth: L2CAP: Start servicing configuration request from remote
- https://gerrit.zephyrproject.org/r/2079 : Bluetooth: L2CAP: Introduce CoC channel states
- https://gerrit.zephyrproject.org/r/2948 : sensor: add driver for MAX44009 light sensor
- https://gerrit.zephyrproject.org/r/2895 : nanokernel: modifying nanokernel to remove duplicate symbols in image file
- https://gerrit.zephyrproject.org/r/2949 : QMSI/uart: Use IOAPIC_EDGE instead of IOAPIC_LEVEL

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/2963 : net: buf: Add fragmentation API support
- https://gerrit.zephyrproject.org/r/2950 : Bluetooth: L2CAP: Make l2cap_chan_add initialize the destroy callback
- https://gerrit.zephyrproject.org/r/2961 : Bluetooth: SMP: Take advantage of new bt_hex helper
- https://gerrit.zephyrproject.org/r/2960 : Bluetooth: Add hexadecimal conversion logging helper
- https://gerrit.zephyrproject.org/r/2955 : Bluetooth: Fix enabling ECDH HCI events when SMP is not selected
- https://gerrit.zephyrproject.org/r/2958 : net: buf: Add big-endian helpers
- https://gerrit.zephyrproject.org/r/2957 : net: buf: Add net_buf_reserve() API
- https://gerrit.zephyrproject.org/r/2956 : net: buf: Use precise buffer size given to NET_BUF_POOL
- https://gerrit.zephyrproject.org/r/2959 : net: buf: Add net_buf_push_u8() helper API


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 1
[ZEP-518] SPI not working on Arduino101
https://jira.zephyrproject.org/browse/ZEP-518


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/2953 : x86: merge IAMCU and SYS V core arch code
- https://gerrit.zephyrproject.org/r/2957 : net: buf: Add net_buf_reserve() API
- https://gerrit.zephyrproject.org/r/2959 : net: buf: Add net_buf_push_u8() helper API
- https://gerrit.zephyrproject.org/r/2958 : net: buf: Add big-endian helpers

MERGED within last 24 hours:


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 6
[ZEP-540] add generic APIs for asynchronous IRQ handlers
https://jira.zephyrproject.org/browse/ZEP-540

[ZEP-536] Update SDK ARC GCC compiler with last toolchain release
https://jira.zephyrproject.org/browse/ZEP-536

[ZEP-538] doc: missing steps to boot up Galileo Gen 2 with a USB flash drive
https://jira.zephyrproject.org/browse/ZEP-538

[ZEP-534] Scan for consistent use of "platform/board/SoC" in documentation
https://jira.zephyrproject.org/browse/ZEP-534

[ZEP-537] doc: create external wiki page "Maintainers"
https://jira.zephyrproject.org/browse/ZEP-537

[ZEP-539] Jenkins marks patches -1 verified for style issues
https://jira.zephyrproject.org/browse/ZEP-539


UPDATED JIRA items within last 24 hours: 3
[ZEP-416] MQTT client capability: QoS1, QoS2
https://jira.zephyrproject.org/browse/ZEP-416

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

[ZEP-423] Quark D2000 CRB documentation should include instructions to flash bootloader
https://jira.zephyrproject.org/browse/ZEP-423


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 3
[ZEP-463] (Fixed) Getting started guide "next" link doesn't take you to "Checking Out the Source Code Anonymously" section
https://jira.zephyrproject.org/browse/ZEP-463

[ZEP-525] (Fixed) srctree changes are breaking applications
https://jira.zephyrproject.org/browse/ZEP-525

[ZEP-514] (Fixed) memory corruption in microkernel memory pool defrag()
https://jira.zephyrproject.org/browse/ZEP-514

7181 - 7200 of 8189