Date   

Naming both a top-level directory and a branch "net" is a bit unfortunate

Paul Sokolovsky
 

Hello,

Today I tried to figure why I got my Zephyr repository clone in an
inconsistent state, and here's what I found:

Git for quite a few years allow to checkout a remote's repository with:

git checkout <short-remote-name>

e.g.

git checkout net

is supposed to just checkout origin/net if didn't have it already, and
set it up a tracking remote branch.

Well, that doesn't work with Zephyr, because there's "net" top-level
directory. It's easy to overlook that "git checkout net" didn't produce
a notice of switching to another branch/setting up tracking, and wonder
why you didn't have the latest net's commits in git log. My next step
was to pull these branch changes explicitly: "git pull --rebase origin
net", and that's how I ended up with net's commit in my master branch.


I hope it's just me, but posting this in case someone else will have a
similar problem (or if maintainers get similar hard-to-explain reports
of "my local repo got messed up!").

The solution is to use explit --track option:

git checkout -b net --track origin/net

(I didn't have to use --track explicitly for a couple of years).


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Porting to Cortex-M0+

Vinicius Costa Gomes
 

Hi,

Euan Mutch <euan.mutch(a)gmail.com> writes:

I have started writing the drivers for peripherals on the M0+ now, but
I am getting the feeling that I should probably just add Atmel ASF to
the \ext\hal\ folder rather than basically rewriting them. I am just
wondering why this was not done already for the Arduino Due which also
has an Atmel SOC?
Licensing issues perhaps[1]?

"Disclaimer and Credits

...

4. This software may only be redistributed and used in connection with
an Atmel microcontroller product."


[1] http://www.atmel.com/Images/asf-releasenotes-3.32.0.pdf page 34


Cheers,
--
Vinicius


Reliability of Gerrit/Jira server

Paul Sokolovsky
 

Hello,

I more or less regularly (e.g., once a day) get following when pull
from the Zephyr repo:

$ git pull --rebase
fatal: unable to access 'https://gerrit.zephyrproject.org/r/zephyr/':
GnuTLS recv error (-9): A TLS packet with unexpected length was
received.

Also, sometimes, it takes quite a while to open a particular ticket in
Jira.

That's not too serious though, so I'm mostly posting to help
maintainers track (perceived) reliability of the project infrastructure
over time.

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


offsetof() in array sizes

Carles Cufi
 

Hi there,

If one includes a offsetof() statement inside a macro that is then used to size an array, the following warning is issued by GCC:

warning: variably modified <VAR_NAME> at file scope

The fix for this, at least for GCC, is to use:

#if defined(__GNUC__)
#define offsetof(s, m) __builtin_offsetof(s, m)
#else
#define offsetof(s, m) ((size_t)(&(((s *)0)->m)))
#endif

Any thoughts about this particular matter? We'd like to use offsetof() when sizing arrays in the BLE Controller but we don't want to duplicate the offsetof() macro.

Thanks,

Carles


Re: _Swap crash in attempt to add support for STM32F3 board

Maciek Borzecki <maciek.borzecki@...>
 

On Mon, Aug 22, 2016 at 4:46 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Thank you for sharing your port, it was really helpful and my work is
heavily based on that.

FYI I now also have a STM32F3 Discovery board working (only clock and
gpio so far). Will also implement GPIO IRQ support. But then I plan to
start cleaning up and attempt to mainline. Will do the uart part later
since it is significantly different compared to F1 and F4.

I am not sure about your timeline, but we could end up clashing with
our ports. So I am unsure how it is best to proceed forward in
attempting to mainline.

I will happily move forward in a join effort.

My port is available on https://github.com/mirzak/zephyr-os/tree/stm32f3
Author of SM32F1 port here. I started working on STM32F3 back in March
and most of the changes I did at that time were pushed here:
https://github.com/bboozzoo/zephyr/commits/bboozzoo/stm32f3
The idea was to extract common pieces of STM32 functionality and have
individual STM32[FL]x ports provide chip specific overrides. That was
before external libraries were introduced, so I guess I would
reevaluate the approach if I were to start now.

Anyways, since then I have moved to other projects. However guys from
my team used the that tree as a base for their F3/F4 ports that AFAIK
are currently being shipped as part of a commercial project for one of
our customers (along with drivers for DAC and some sensors). Also, the
port was supposed to be posted for upstream review at some point.

I believe they should be subscribed to devel, but I will ping them to
check their status once I get back from vacation next week.

Cheers,
--
Maciek Borzecki


Re: Porting to Cortex-M0+

Euan Mutch <euan.mutch@...>
 

I have started writing the drivers for peripherals on the M0+ now, but I am getting the feeling that I should probably just add Atmel ASF to the \ext\hal\ folder rather than basically rewriting them. I am just wondering why this was not done already for the Arduino Due which also has an Atmel SOC?


Re: _Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

2016-08-22 18:38 GMT+02:00 Amit Kucheria <amit.kucheria(a)verdurent.com>:

Mirza,

I expect we'll start cleaning up our port in a week or two. I'm trying
to finish up the SPI driver before starting a cleanup.
Hi Amit.

Good to know that you are working on a SPI driver, I was planing on
doing that as well. Now I wont :).

I will wait for your clean-up then, I will be going on vacation next
week and I am probably not gonna finish anything until then.

Best Regards
Mirza


Re: having trouble getting the echo client to work using TCP/uIP on K64F

Morgaine
 

This state of play with FRDM-K64F is really quite unexpected. Freescale
and their new owners NXP are after all *founding members* of the Zephyr
Project, and FRDM-K64F is not only their leading FRDM-series board but it
is also the only NXP board which is explicitly listed as Supported.

Given the above, it would be very reasonable for any reader to assume that
at least this one board would be excellently supported by Zephyr (as a
result of NXP's support), especially in regard to its key features like
built-in networking. Evidently that would be a false assumption.

Do founding members of the project not offer to provide manpower support or
running code, at least for their own boards?

I think it would be useful to understand the relationship between
sponsoring corporations and the project better. Despite operating under
the umbrella of the Linux Foundation, code contributions in Zephyr may
differ from the Linux model, for which companies commonly contribute kernel
code for their hardware.

If this is written down somewhere already, a link would be awesome.
Thanks! :-)

Morgaine.


Re: _Swap crash in attempt to add support for STM32F3 board

Amit Kucheria
 

On Mon, Aug 22, 2016 at 8:16 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Thank you for sharing your port, it was really helpful and my work is
heavily based on that.

FYI I now also have a STM32F3 Discovery board working (only clock and
gpio so far). Will also implement GPIO IRQ support. But then I plan to
start cleaning up and attempt to mainline. Will do the uart part later
since it is significantly different compared to F1 and F4.

I am not sure about your timeline, but we could end up clashing with
our ports. So I am unsure how it is best to proceed forward in
attempting to mainline.

I will happily move forward in a join effort.

My port is available on https://github.com/mirzak/zephyr-os/tree/stm32f3
Mirza,

I expect we'll start cleaning up our port in a week or two. I'm trying
to finish up the SPI driver before starting a cleanup.

Cheers,
Amit


Re: Implementation for QMSI SPI driver - burst mode

Tomasz Bursztyka
 

Hi Mahendravarman,

Please help me on the following

We have connected a BMA255 accelerometer in the SPI of Atlas peak.
BMA255 has a FIFO data readout register (0x3F). This register should be read as a BURST mode ( the address is 0x3F , but we need to initiate burst mode)
Expected data to be read from the register (0x3F) is 192 bytes

1. Will the SPI_transceive function will support burst mode ??
Sure, I don't see why it would not.


2. For the above use case of BMA255 , should I need to issue function as below for SPI burst read

cnt = 192 ;
iError = spi_transceive(dev_addr, array, cnt+1,array, cnt+1);
Yes, make sure the array provides the dummy bytes (0s).

Have a look at drivers/sensors/sensor_bma* , I believe some do have such
reading.

Br,

Tomasz


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 3
[ZEP-433] (Won't Do) Unclear how to obtain Arduino 101 "original bootloader" for dfu-util operation
https://jira.zephyrproject.org/browse/ZEP-433

[ZEP-478] (Fixed) Linux setup docs missing step to install curses development package for Fedora
https://jira.zephyrproject.org/browse/ZEP-478

[ZEP-516] (Fixed) Ubuntu setup instructions missing 'upgrade' step
https://jira.zephyrproject.org/browse/ZEP-516


RESOLVED JIRA items within last 24 hours: 9
[ZEP-650] (Fixed) Quark SE: Implement PM reference application
https://jira.zephyrproject.org/browse/ZEP-650

[ZEP-662] (Fixed) QMSI shim driver: Pinmux: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-662

[ZEP-658] (Fixed) QMSI shim driver: GPIO: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-658

[ZEP-659] (Fixed) QMSI shim driver: UART: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-659

[ZEP-655] (Fixed) QMSI shim driver: PWM: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-655

[ZEP-652] (Fixed) QMSI shim driver: RTC: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-652

[ZEP-616] (Fixed) OS X setup instructions not working on El Capitan
https://jira.zephyrproject.org/browse/ZEP-616

[ZEP-583] (Cannot Reproduce) "make debugserver" get "lakemont_halt" @quark_se_devboard
https://jira.zephyrproject.org/browse/ZEP-583

[ZEP-708] (Fixed) tests/kernel/test_ipm fails on Arduino 101
https://jira.zephyrproject.org/browse/ZEP-708


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4225 : net: raising MAX_TCP_RETRY_COUNT to account for slower response
- https://gerrit.zephyrproject.org/r/4226 : uIP: don't fill in TCP option bytes (in header) for all packets
- https://gerrit.zephyrproject.org/r/4219 : net: Add TODO items for L2 and 802.15.4
- https://gerrit.zephyrproject.org/r/4221 : Bluetooth: L2CAP: Fix reset channel state context
- https://gerrit.zephyrproject.org/r/4220 : Bluetooth: L2CAP: Refactor connection security handler
- https://gerrit.zephyrproject.org/r/4214 : doc: Add more content for networking documentation

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4028 : Bluetooth: ATT: Make it safe to access the request list
- https://gerrit.zephyrproject.org/r/4027 : Bluetooth: GATT: Add queuing support
- https://gerrit.zephyrproject.org/r/4081 : power_mgmt: Updated Power Management device driver API
- https://gerrit.zephyrproject.org/r/3997 : Bluetooth: L2CAP: Implement connect command on BR/EDR
- https://gerrit.zephyrproject.org/r/4090 : Bluetooth: Controller: Add driver that glues Link Layer with the BLE stack
- https://gerrit.zephyrproject.org/r/4086 : Bluetooth: Controller: Hardware abstraction layer for nRF5x radio
- https://gerrit.zephyrproject.org/r/4168 : net: samples: Add a simple Qemu sample for testing off-line 802.15.4
- https://gerrit.zephyrproject.org/r/4165 : net: drivers: Add a fake ieee802154 radio driver for qemu
- https://gerrit.zephyrproject.org/r/4167 : samples: net: Qemu make utilities update
- https://gerrit.zephyrproject.org/r/4166 : samples: net: Moving the current ieee802154 sample
- https://gerrit.zephyrproject.org/r/4202 : net: ip: Fix compiling with 15.4
- https://gerrit.zephyrproject.org/r/4091 : board: nrf52_pca10040: Include Controller by default in board nrf52_pca10040
- https://gerrit.zephyrproject.org/r/4089 : Bluetooth: Controller: A full, hardware-agnostic Link Layer implementation
- https://gerrit.zephyrproject.org/r/4087 : Bluetooth: Controller: Add a util folder with basic primitives
- https://gerrit.zephyrproject.org/r/4088 : Bluetooth: Controller: Initial impl. of a HCI controller-side interface

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4215 : Bluetooth: RFCOMM: Handle data and credit from peer
- https://gerrit.zephyrproject.org/r/4212 : Bluetooth: RFCOMM: Perform MSC transaction after dlc
- https://gerrit.zephyrproject.org/r/4213 : Bluetooth: RFCOMM: Move rfcomm_make_uih_msg() up
- https://gerrit.zephyrproject.org/r/4211 : Merge remote-tracking branch 'origin/master' into net
- https://gerrit.zephyrproject.org/r/4200 : net: samples: Fix slip config for echo-server and echo-client
- https://gerrit.zephyrproject.org/r/4201 : net: samples: Fix the echo-server IPv6 address
- https://gerrit.zephyrproject.org/r/4196 : net: TODO file for networking
- https://gerrit.zephyrproject.org/r/4144 : net: tests: Enable unit tests for the new IP stack
- https://gerrit.zephyrproject.org/r/4199 : net: Clarify the CONFIG_NET_TESTING setting
- https://gerrit.zephyrproject.org/r/4203 : net: samples: Fix the location of net-tools project files


Implementation for QMSI SPI driver - burst mode

Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi Tomasz

Please help me on the following

We have connected a BMA255 accelerometer in the SPI of Atlas peak.
BMA255 has a FIFO data readout register (0x3F). This register should be read as a BURST mode ( the address is 0x3F , but we need to initiate burst mode)
Expected data to be read from the register (0x3F) is 192 bytes

1. Will the SPI_transceive function will support burst mode ??

2. For the above use case of BMA255 , should I need to issue function as below for SPI burst read

cnt = 192 ;
iError = spi_transceive(dev_addr, array, cnt+1,array, cnt+1);






Best regards

Mahendravarman Rajarao

-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Wednesday, July 06, 2016 11:16 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>
Subject: Re: [devel] Re: Re: Re: Re: Re: Need Callback Implementation for QMSI SPI driver

Hi Mahendravarman,

Please help me on the following

I have a query.
In the qmsi SPI driver under the spi_qmsi_transceive function its
stated as

/* FIXME: QMSI expects rx_buf_len and tx_buf_len to
* have the same size. */

So, the current driver has dependency that rx_buf_len and tx_buf_len has to be same size.
Yes it's a regression in QMSI side: it does not support asymmetric buffer though zephyr's spi api (include/spi.h) does.

SPI API was designed to let the driver handling dummy bytes. You send 2 bytes, waiting to read 10 bytes in return would mean the driver would have to send 8 dummy bytes after the 2 first command bytes.
Dummy bytes are just zeros.

With QMSI, you cannot let the driver do that for you so you have to think about these "dummy bytes" yourself.


In our BLE module, we have a requirement that, When we pass 4 bytes of SPI write command, BLE module sends 8 bytes of data ..
Is that possible to handle the above situation using SPI_read and SPI _write calls in the present driver ??
You still have to use spi_transceive. Basically, it's up to your BLE module to handle the SPI dummy bytes.
So you have to provide symmetric rx/tx buffers. In your case you could do:

uint8_t buf[8] = {};

buf[0] = your_1st_byte;
buf[1] = your_2nd_byte;

spi_transceive(spi_dev, buf, 8, buf, 8);

SPI is serialized, always. So 1 byte sent will mean 1 byte read. That's why, in this example, I use the same buffer in rx/tx. (It will never ever happen that your receive more than what you wrote. Or then it's a serious bug in the spi driver.)

Hope it answers your question. Don't hesitate to ask if you have more unclear stuff.

Br,

Tomasz


Thanks


-----Original Message-----
From: Mahendravarman Rajarao (RBEI/EAA3)
Sent: Thursday, June 30, 2016 12:22 PM
To: 'Tomasz Bursztyka' <tomasz.bursztyka(a)linux.intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: Need Callback Implementation
for QMSI SPI driver


Hi

Sorry typo error
We plan to use AON GPIO call back itself in case of any BLE Activity.



-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Thursday, June 30, 2016 12:22 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: Need Callback Implementation for
QMSI SPI driver

Hi,

Indeed, not using AON would have been surprising. :)

Tomasz

Hi

We are using MCU x86 Core
We have connected a GPIO line from BLE module to the MCU x86's AON GPIO.
Based on your discussion below I think we can use GPIO call back itself in case of any BLE Activity.

Thanks


-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Tuesday, June 28, 2016 3:03 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Need Callback Implementation for QMSI
SPI driver

Hi,
We have connected MCU SPI to a BLE module.
BLE module will wakeup MCU from sleep state through SPI interrupt
During that time we need a callback implementation in SPI driver
Are you talking about the MCU's ARC core or x86 core?
This makes quite a difference.

I would be surprised you hook up the BLE only to SPI, don't you have
a GPIO line to tell about BLE activity? In case of ARC core, any GPIO
interrupt actually wakes up the core, if I am not mixing up. (input
ones are wake capable, on level trigger)

Is you BLE lined up as an SPI slave or as an master? (only x86 core's SPI supports being wired as a slave against an external master if I remember well).
BLE as a slave, it would not be able to generate any interrupt through SPI.
On x86, only AON GPIO can be used to wake up, from external activity.

Please detail. In both case, there is no need of ISR context SPI user callback.
But there are implementations implications though.

Tomasz


having trouble getting the echo client to work using TCP/uIP on K64F

Rohit Grover
 

Hello Community,

I've still not been able to get a TCP stream going over uIP using the echo-client sample.
I've unearthed problems along the way (including data-integrity issues in Zephyr's port of uIP; refer to https://gerrit.zephyrproject.org/r/#/c/4226/ ) which suggest that this kind of thing isn't actively tested. With my recent changes, I manage to get the first packet bounce back successfully to the echo-client. Successive packets aren't getting processed on their way out from the client.

I find that uip_process() isn't getting called on successive packets. It gets called for the first packet due to some retransmission timer. The recently made change to eventhandler() in tcpip.c (https://gerrit.zephyrproject.org/r/#/c/4050/) makes things worse because the code meant to refresh certain periodic timers gets skipped.

These issues seem to arise from uIP. I would appreciate some help from people who ported uIP to zephyr. I believe the problems will surface if someone tries a TCP/IPV4 stream.

rohit
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: _Swap crash in attempt to add support for STM32F3 board

Mirza Krak
 

2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Thank you for sharing your port, it was really helpful and my work is
heavily based on that.

FYI I now also have a STM32F3 Discovery board working (only clock and
gpio so far). Will also implement GPIO IRQ support. But then I plan to
start cleaning up and attempt to mainline. Will do the uart part later
since it is significantly different compared to F1 and F4.

I am not sure about your timeline, but we could end up clashing with
our ports. So I am unsure how it is best to proceed forward in
attempting to mainline.

I will happily move forward in a join effort.

My port is available on https://github.com/mirzak/zephyr-os/tree/stm32f3

Best Regards,
Mirza Krak


Re: [RFC] Power Management Infrastructure

Kaplan, Amir
 

Hi all,

I did Abandon to the split changes and Restored the previous all in one patch.
Also I correct some things according to your comments.

The Restored link is:

https://gerrit.zephyrproject.org/r/4081

Thanks,
Amir Kaplan

-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 13:36
To: devel(a)lists.zephyrproject.org
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,

The corresponding Gerrit link:
https://gerrit.zephyrproject.org/r/4081



-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 11:18
To: 'devel(a)lists.zephyrproject.org' <devel(a)lists.zephyrproject.org>
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kaplan, Amir <amir.kaplan(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,
After reviewing all the comments and consulting Ramesh, below is the updated RFC:

Current state
===========

In the current Zephyr implementation the driver power hooks distinguish only between two driver states (suspend and resume). Drivers may have more than two states (i.e. D-states) and can traverse between those states. The state change today is limited only from active to suspend while there can be cases of other transitions requested by the application.
Please look at the below suggested device power states E.g. transition between DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an application or a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {
int (*suspend)(struct device *device, int pm_policy);
int (*resume)(struct device *device, int pm_policy); };

Proposed changes
===============

1. Have one function that can be used for all possible device PM purposes using a control code instead of the suspend resume functions:

int (*device_pm_control)(struct device *device, int pm_command, int device_power_state);

In first version will support DEVICE_SET_POWER_STATE and DEVICE_GET_POWER_STATE commands.

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

3. The set state functionality (via device_pm_control ) 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 set state functionality (via device_pm_control ) will enable the Power Manager service to know the state of a driver if needed thus enable it to configure the SoC power behavior.

The advantages in the new method:
1. Active device PM that does not need system to go idle to do device PM. Any component can call it. Multiple PM states and transitions need not always between active and low power states.
2. Reduces memory use and complexity because now there is only one function.
3. Compatible with legacy suspend/resume done from central PMA during idle 4. Scalable- In future more control codes can be added to support other device pm operations without having to change infrastructure.

Regards,
Amir, Keren, Hezi

-----Original Message-----
From: Rahamim, Hezi
Sent: Wednesday, August 10, 2016 10:18
To: Kaplan, Amir <amir.kaplan(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>
Subject: FW: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



-----Original Message-----
From: Thomas, Ramesh
Sent: Friday, July 15, 2016 06:22
To: Rahamim, Hezi <hezi.rahamim(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



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

UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 3
[ZEP-538] (Fixed) doc: missing steps to boot up Galileo Gen 2 with a USB flash drive
https://jira.zephyrproject.org/browse/ZEP-538

[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


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4081 : fix doxygen error doc: Update Power Management device driver API 1. Have one function that can be used for all possible device PM purposes using a control code instead of the suspend resume functions. 2. Add the below device power states: Note: Many devic

MERGED within last 24 hours:


Re: [RFC] Power Management Infrastructure

Kaplan, Amir
 

Hi all,

I did Abandon to all the below patches and will deliver again as one big change (please note: all the drivers changes are quite similar) .


Thanks,
Amir Kaplan

-----Original Message-----
From: Kaplan, Amir
Sent: Thursday, August 18, 2016 12:04
To: 'devel(a)lists.zephyrproject.org' <devel(a)lists.zephyrproject.org>
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>; Kidron, Amihai <amihai.kidron(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi,
Following Ramesh and Ku-Lang's feedbacks we have split the changes to multiple small patches(instead of the original delivery).

Note: Due to the fact that the drivers changes depends on the change in device.h only the last delivery(https://gerrit.zephyrproject.org/r/#/c/4161/) passes all required verifications in Jenkins.

Below are the updated deliveries:
Device API:
https://gerrit.zephyrproject.org/r/#/c/4142/

gpio:
https://gerrit.zephyrproject.org/r/#/c/4143/

interrupt_controler:
https://gerrit.zephyrproject.org/r/#/c/4145/

pwm:
https://gerrit.zephyrproject.org/r/#/c/4147/

rtc:
https://gerrit.zephyrproject.org/r/#/c/4148/

uart:
https://gerrit.zephyrproject.org/r/#/c/4149/

spi:
https://gerrit.zephyrproject.org/r/#/c/4150/

timer:
https://gerrit.zephyrproject.org/r/#/c/4159/

samples:
https://gerrit.zephyrproject.org/r/#/c/4161/

Regards,
Amir & Keren

-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 13:36
To: devel(a)lists.zephyrproject.org
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,

The corresponding Gerrit link:
https://gerrit.zephyrproject.org/r/4081


-----Original Message-----
From: Kaplan, Amir
Sent: Monday, August 15, 2016 11:18
To: 'devel(a)lists.zephyrproject.org' <devel(a)lists.zephyrproject.org>
Cc: Rahamim, Hezi <hezi.rahamim(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>; Kaplan, Amir <amir.kaplan(a)intel.com>; Kanner, Noa <noa.kanner(a)intel.com>
Subject: RE: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure

Hi all,
After reviewing all the comments and consulting Ramesh, below is the updated RFC:

Current state
===========

In the current Zephyr implementation the driver power hooks distinguish only between two driver states (suspend and resume). Drivers may have more than two states (i.e. D-states) and can traverse between those states. The state change today is limited only from active to suspend while there can be cases of other transitions requested by the application.
Please look at the below suggested device power states E.g. transition between DEVICE_PM_LOW_POWER_STATE to DEVICE_PM_OFF_STATE.

Moreover, the current device state cannot be queried by an application or a Power Manager service.

Below is the current Zephyr PM hooks:

struct device_pm_ops {
int (*suspend)(struct device *device, int pm_policy);
int (*resume)(struct device *device, int pm_policy); };

Proposed changes
===============

1. Have one function that can be used for all possible device PM purposes using a control code instead of the suspend resume functions:

int (*device_pm_control)(struct device *device, int pm_command, int device_power_state);

In first version will support DEVICE_SET_POWER_STATE and DEVICE_GET_POWER_STATE commands.

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

3. The set state functionality (via device_pm_control ) 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 set state functionality (via device_pm_control ) will enable the Power Manager service to know the state of a driver if needed thus enable it to configure the SoC power behavior.

The advantages in the new method:
1. Active device PM that does not need system to go idle to do device PM. Any component can call it. Multiple PM states and transitions need not always between active and low power states.
2. Reduces memory use and complexity because now there is only one function.
3. Compatible with legacy suspend/resume done from central PMA during idle 4. Scalable- In future more control codes can be added to support other device pm operations without having to change infrastructure.

Regards,
Amir, Keren, Hezi

-----Original Message-----
From: Rahamim, Hezi
Sent: Wednesday, August 10, 2016 10:18
To: Kaplan, Amir <amir.kaplan(a)intel.com>; Siman-tov, Keren <keren.siman-tov(a)intel.com>
Subject: FW: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



-----Original Message-----
From: Thomas, Ramesh
Sent: Friday, July 15, 2016 06:22
To: Rahamim, Hezi <hezi.rahamim(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: Re: [RFC] Power Management Infrastructure



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.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

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


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-724] build on windows failed: 'make: execvp: uname: File or path name too long'
https://jira.zephyrproject.org/browse/ZEP-724

[ZEP-725] CI tag build is not sending emails
https://jira.zephyrproject.org/browse/ZEP-725


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

[ZEP-616] OS X setup instructions not working on El Capitan
https://jira.zephyrproject.org/browse/ZEP-616

[ZEP-172] tests/kernel/test_task_priv/test FAILED in QEMU
https://jira.zephyrproject.org/browse/ZEP-172

[ZEP-669] MQTT fail to pingreq if broker deliver topic to client but client doesn't read it.
https://jira.zephyrproject.org/browse/ZEP-669

[ZEP-697] samples/net/test_15_4 cannot be built by sanitycheck
https://jira.zephyrproject.org/browse/ZEP-697

[ZEP-632] MQTT fail to re-connect to the broker.
https://jira.zephyrproject.org/browse/ZEP-632

[ZEP-145] no 'make flash' for Arduino Due
https://jira.zephyrproject.org/browse/ZEP-145

[ZEP-639] device_pm_ops structure should be defined as static
https://jira.zephyrproject.org/browse/ZEP-639

[ZEP-528] ARC has 2 almost identical copies of the linker script
https://jira.zephyrproject.org/browse/ZEP-528


CLOSED JIRA items within last 24 hours: 39
[ZEP-242] (Fixed) Collaboration Guidelines Restructure
https://jira.zephyrproject.org/browse/ZEP-242

[ZEP-270] (Fixed) nios2: determine optimal value for PERFOPT_ALIGN
https://jira.zephyrproject.org/browse/ZEP-270

[ZEP-643] (Fixed) Add file system API documentation
https://jira.zephyrproject.org/browse/ZEP-643

[ZEP-590] (Fixed) Update Zephyr's tinycrypt to version 2.0
https://jira.zephyrproject.org/browse/ZEP-590

[ZEP-621] (Fixed) samples/static_lib: fatal error: stdio.h: No such file or directory
https://jira.zephyrproject.org/browse/ZEP-621

[ZEP-617] (Fixed) MQTT samples build fail because netz.h file missing.
https://jira.zephyrproject.org/browse/ZEP-617

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

[ZEP-460] (Fixed) doc: document parameters of DEVICE* macros
https://jira.zephyrproject.org/browse/ZEP-460

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

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

[ZEP-646] (Fixed) I2C fail to read GY2561 sensor when GY2561 & GY271 sensor are attached to I2C bus.
https://jira.zephyrproject.org/browse/ZEP-646

[ZEP-623] (Fixed) MQTT sample mqtt.h missing "mqtt_unsubscribe" function
https://jira.zephyrproject.org/browse/ZEP-623

[ZEP-647] (Fixed) Power management state storage should use GPS1 instead of GPS0
https://jira.zephyrproject.org/browse/ZEP-647

[ZEP-645] (Fixed) ARC QMSI ADC shim driver fails to read sample data
https://jira.zephyrproject.org/browse/ZEP-645

[ZEP-595] (Fixed) UART: usb simulated uart doesn't work in poll mode
https://jira.zephyrproject.org/browse/ZEP-595

[ZEP-572] (Fixed) X86 kernel BAT failed: Kernel Allocation Failure!
https://jira.zephyrproject.org/browse/ZEP-572

[ZEP-581] (Fixed) test_sha256 fails on Nios II if CONFIG_DEBUG=y
https://jira.zephyrproject.org/browse/ZEP-581

[ZEP-571] (Fixed) ARC kernel BAT failed due to race in nested interrupts
https://jira.zephyrproject.org/browse/ZEP-571

[ZEP-526] (Fixed) build "kernel event logger" sample app failed for BOARD=quark_d2000_crb
https://jira.zephyrproject.org/browse/ZEP-526

[ZEP-523] (Fixed) FIFOs defined by DEFINE_FIFO macro use the same memory buffer
https://jira.zephyrproject.org/browse/ZEP-523

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

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

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

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

[ZEP-499] (Fixed) TMP007 driver returns invalid values for negative temperature
https://jira.zephyrproject.org/browse/ZEP-499

[ZEP-474] (Fixed) ND: Neighbor cache is not getting cleared
https://jira.zephyrproject.org/browse/ZEP-474

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

[ZEP-428] (Won't Do) Ethernet/IPv4/TCP net_send error
https://jira.zephyrproject.org/browse/ZEP-428

[ZEP-681] (Fixed) MQTT client sample throws too many warnings when build.
https://jira.zephyrproject.org/browse/ZEP-681

[ZEP-673] (Fixed) Sanity crashes and doesn't kill qemu upon timeout
https://jira.zephyrproject.org/browse/ZEP-673

[ZEP-679] (Fixed) HMC5883L I2C Register Read Order
https://jira.zephyrproject.org/browse/ZEP-679

[ZEP-556] (Fixed) System hangs during I2C transfer
https://jira.zephyrproject.org/browse/ZEP-556

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

[ZEP-457] (Fixed) doc: contribute/doxygen/typedefs.rst: examples files are broken
https://jira.zephyrproject.org/browse/ZEP-457

[ZEP-475] (Fixed) Issue with timer callback routine: Condition checked is incorrect
https://jira.zephyrproject.org/browse/ZEP-475

[ZEP-459] (Fixed) doc: kconfig reference entries in HTML are lacking a title
https://jira.zephyrproject.org/browse/ZEP-459

[ZEP-456] (Fixed) doc: `IDT security` section dissapeared
https://jira.zephyrproject.org/browse/ZEP-456

[ZEP-379] (Fixed) _k_command_stack may be improperly initialized when debugging
https://jira.zephyrproject.org/browse/ZEP-379

[ZEP-180] (Fixed) make menuconfig user provided options are ignored at building time
https://jira.zephyrproject.org/browse/ZEP-180


RESOLVED JIRA items within last 24 hours: 12
[ZEP-55] (Fixed) enable nanokernel test_context on ARC
https://jira.zephyrproject.org/browse/ZEP-55

[ZEP-704] (Fixed) test_atomic does not complete on ARC
https://jira.zephyrproject.org/browse/ZEP-704

[ZEP-461] (Fixed) Release 1.4.0 has broken the BMI160 sample as well as an application based on it
https://jira.zephyrproject.org/browse/ZEP-461

[ZEP-612] (Won't Do) Need to send a dummy packet to establish connection using the TCP/IP stack
https://jira.zephyrproject.org/browse/ZEP-612

[ZEP-369] (Fixed) When building out of the tree, application object files are not placed into outdir
https://jira.zephyrproject.org/browse/ZEP-369

[ZEP-455] (Won't Do) Sensor DHT11/DHT22 Fails to perform repetitive sampling with Zephyr
https://jira.zephyrproject.org/browse/ZEP-455

[ZEP-384] (Fixed) D2000 hangs after I2C communication with BMC150 sensor
https://jira.zephyrproject.org/browse/ZEP-384

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

[ZEP-598] (Fixed) CoAP Link format filtering is not supported
https://jira.zephyrproject.org/browse/ZEP-598

[ZEP-695] (Fixed) FatFs doesn't compile using Newlib
https://jira.zephyrproject.org/browse/ZEP-695

[ZEP-68] (Fixed) Final image contains duplicates of some routines
https://jira.zephyrproject.org/browse/ZEP-68

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

6761 - 6780 of 8036