Date   

Daily JIRA Digest

donotreply@...
 

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

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

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


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


CLOSED JIRA items within last 24 hours: 0

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

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

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

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

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

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

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

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

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


Daily Gerrit Digest

donotreply@...
 

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

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

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


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

Boie, Andrew P
 

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

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


Regards,
Andrew


Re: [RFC] Power Management Infrastructure

Thomas, Ramesh
 

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

Please see my comments below.

Regards,
Hezi

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

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

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

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

int device_pm_control(device, flags);

flags = (CONTROL_CODE | SYSTEM_POWER_STATE | DEVICE_POWER_STATE)

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

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

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

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

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


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



Thanks for the comment,
Hezi

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

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

Regards,

Dmitriy Korovkin

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

Please see my comments below/

Thanks for the comments,
Hezi

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

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

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

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


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

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

transitions requested by the application.

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

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

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

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

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

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

};

Proposed changes

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

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

instead of the suspend resume functions:

struct device_pm_ops {

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

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

};

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

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

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

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



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

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

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

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

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

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

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

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

DEVICE_PM_ACTIVE_STATE

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

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

DEVICE_PM_LOW_POWER_STATE

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

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

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

DEVICE_PM_SUSPEND_STATE

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

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context
lost

by the hardware.

The device can be powered down.

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

DEVICE_PM_OFF_STATE

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

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

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

when powering it back on.

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

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

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



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

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

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

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

Comments/concerns welcome.

Thanks,

Hezi

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

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

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

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


Re: [RFC] Power Management Infrastructure

Thomas, Ramesh
 

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

Please find comments below.

Regards,
Alex.

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

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

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

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

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



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


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

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


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

Liu, Baohong
 

Hi,

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

This is based on ZEP-235.

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

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

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

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

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

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

Welcome feedback/comments or any concerns.

Thanks,
Baohong


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

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

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

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

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

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


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


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

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

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


Daily Gerrit Digest

donotreply@...
 

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

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

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


Re: [RFC] Zephyr Shell Enhancement

Luiz Augusto von Dentz
 

Hi Yael,

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

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



========

Overview

========

Current shell implementation:

• Current Shell implementation is based on UART.

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



• Console device driver initialization priority:

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



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

initialize UART console.



• Current shell implementation supplies shell utilities only for a
single

module.



=====

Goals

=====

1. Multiple and dynamic usage in modules level:

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

Ability to add multiple modules to shell commands array.

Each module should be added dynamically by its config file.



2. Dynamic usage of the shell:

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

Ability to enable / disable shell service.

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

are also available for use.



3. Memory consumption:

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

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

entities that actually use the shell.



4. Shell format:

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

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

- ENTITY COMMAND

- help

- help ENTITY

- help ENTITY COMMAND

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


Re: [RFC] Power Management Infrastructure

Rahamim, Hezi
 

Hi Ramesh'

Please see my comments below.

Regards,
Hezi

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

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

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

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

int device_pm_control(device, flags);

flags = (CONTROL_CODE | SYSTEM_POWER_STATE | DEVICE_POWER_STATE)

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

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

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

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

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


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



Thanks for the comment,
Hezi

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

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

Regards,

Dmitriy Korovkin

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

Please see my comments below/

Thanks for the comments,
Hezi

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

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

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

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


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

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

transitions requested by the application.

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

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

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

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

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

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

};

Proposed changes

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

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

instead of the suspend resume functions:

struct device_pm_ops {

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

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

};

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

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

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

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



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

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

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

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

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

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

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

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

DEVICE_PM_ACTIVE_STATE

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

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

DEVICE_PM_LOW_POWER_STATE

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

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

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

DEVICE_PM_SUSPEND_STATE

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

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context
lost

by the hardware.

The device can be powered down.

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

DEVICE_PM_OFF_STATE

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

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

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

when powering it back on.

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

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


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

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

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

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

Comments/concerns welcome.

Thanks,

Hezi

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

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

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

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

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


Re: [RFC] Power Management Infrastructure

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

Hi,

Please find comments below.

Regards,
Alex.

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

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

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

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

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


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


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

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

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


Re: [RFC] Power Management Infrastructure

Thomas, Ramesh
 

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

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

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

int device_pm_control(device, flags);

flags = (CONTROL_CODE | SYSTEM_POWER_STATE | DEVICE_POWER_STATE)

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

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

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

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


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



Thanks for the comment,
Hezi

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

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

Regards,

Dmitriy Korovkin

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

Please see my comments below/

Thanks for the comments,
Hezi

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

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

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

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


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

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

transitions requested by the application.

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

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

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

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

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

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

};

Proposed changes

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

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

instead of the suspend resume functions:

struct device_pm_ops {

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

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

};

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

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

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

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



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

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

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

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

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

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

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

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

DEVICE_PM_ACTIVE_STATE

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

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

DEVICE_PM_LOW_POWER_STATE

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

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

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

DEVICE_PM_SUSPEND_STATE

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

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context lost

by the hardware.

The device can be powered down.

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

DEVICE_PM_OFF_STATE

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

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

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

when powering it back on.

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

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


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

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

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

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


Comments/concerns welcome.

Thanks,

Hezi

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

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

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

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


Re: [RFC] Power Management Infrastructure

Rahamim, Hezi
 

Hi Dimitriy,

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

Thanks for the comment,
Hezi

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

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

Regards,

Dmitriy Korovkin

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

Please see my comments below/

Thanks for the comments,
Hezi

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

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

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

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


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

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

transitions requested by the application.

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

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

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

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

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

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

};

Proposed changes

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

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

instead of the suspend resume functions:

struct device_pm_ops {

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

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

};

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

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

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

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


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

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

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

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

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

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

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

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

DEVICE_PM_ACTIVE_STATE

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

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

DEVICE_PM_LOW_POWER_STATE

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

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

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

DEVICE_PM_SUSPEND_STATE

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

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context lost

by the hardware.

The device can be powered down.

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

DEVICE_PM_OFF_STATE

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

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

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

when powering it back on.

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

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

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

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

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


Comments/concerns welcome.

Thanks,

Hezi

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

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

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

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


Re: [RFC] Power Management Infrastructure

Dmitriy Korovkin
 

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

Regards,

Dmitriy Korovkin

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

Please see my comments below/

Thanks for the comments,
Hezi

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

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

Current state

===========

In the current Zephyr implementation the driver power hooks
distinguish only

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


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

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

transitions requested by the application.

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

DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

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

a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {

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

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

};

Proposed changes

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

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

instead of the suspend resume functions:

struct device_pm_ops {

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

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

};

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

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

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

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


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

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

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

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

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

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

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

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

DEVICE_PM_ACTIVE_STATE

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

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

DEVICE_PM_LOW_POWER_STATE

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

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

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

DEVICE_PM_SUSPEND_STATE

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

Most device context is lost by the hardware.

Device drivers must save and restore or reinitialize any context lost

by the hardware.

The device can be powered down.

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

DEVICE_PM_OFF_STATE

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

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

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

when powering it back on.

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

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

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

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

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


Comments/concerns welcome.

Thanks,

Hezi

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

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

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


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.

7621 - 7640 of 8638