Date   

Re: Device driver configuration and driver_data distinction.

Tomasz Bursztyka
 

Hi Marcus,


Sound sane?
ACK from me at least.

Tomasz


Re: Device driver configuration and driver_data distinction.

Marcus Shawcroft <marcus.shawcroft@...>
 

On 6 October 2016 at 12:06, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com> wrote:
Hi Marcus,

I believe we did not make it const at the beginning due to PCI enumeration
on Galileo.
This was early days, and things changed then.

Actually there have been plans to move it to const, at least I remember
hearing such idea
from Daniel Kalowsky, for the same exact reasons you noted, it might even be
in the git history,
somewhere. But we were too busy to follow up at that time.

So this would indeed be very welcome, if you want to propose a patch for it.
Note, however, that some device drivers may be using such configuration
structure wrongly.
(aka: accessing and changing its data). So you would probably need to change
things there as well.
Hi,

Thanks for the background information.

Switching to const config_info will require the following:
1) Update ~50 drivers with an explicit const in any pointers they
construct when accessing their config_info structure. This change is
safe to make even when struct device {} has a a non const *config_info
2) Update a small subset of the above 50 to make their config
structures static. Not strictly necessary, but seems like the right
thing to do for all those drivers that are self contained within one
file.
3) Update ~12 drivers that currently have RW data within their RO
config data structure. This should be a straight forward mechanical
move of each RW object within config to the corresponding driver_data
structure.
4) Update ~12 drivers to put explict const in any pointers they
construct when accessing config_info
5) Update device {} to make config_info const.
6) Update all ~60 odd drivers to add const to their config structure
definitions.

All of this is mechanical, most trivial, some slightly more involved.
The hard part is likely to be figuring out how to make sure everything
modified gets compiled / tested as appropriate. Each of these steps
can be executed individually and incrementally without breaking the
tree.

3) Is not as difficult as it might first appear since each driver
instance has a RO config structure and a RW driver data structure, it
is essentially a trivial exercise of moving objects from one structure
to the other.

Sound sane?

Cheers
/Marcus


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-1038] Hard real-time interrupt support
https://jira.zephyrproject.org/browse/ZEP-1038

[ZEP-1036] net/yaip: ARP requests error
https://jira.zephyrproject.org/browse/ZEP-1036


UPDATED JIRA items within last 24 hours: 2
[ZEP-917] Add abort handler support
https://jira.zephyrproject.org/browse/ZEP-917

[ZEP-975] DNS client port to new IP stack
https://jira.zephyrproject.org/browse/ZEP-975


CLOSED JIRA items within last 24 hours: 3
[ZEP-668] (Duplicate) Quark SE: Add support for suspend and resume ARC Sensor subsystem when SoC enters/exits Sleep state
https://jira.zephyrproject.org/browse/ZEP-668

[ZEP-656] (Duplicate) QMSI shim driver: Comparator: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-656

[ZEP-660] (Duplicate) QMSI shim driver: DMA: Implement suspend and resume callbacks
https://jira.zephyrproject.org/browse/ZEP-660


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


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/5241 : net: yaip: Add support for 6lo context based compression
- https://gerrit.zephyrproject.org/r/5238 : net: yaip: Add support for 6CO
- https://gerrit.zephyrproject.org/r/5239 : net: tests: Add sample 6CO context data to IPv6 RA test
- https://gerrit.zephyrproject.org/r/5213 : gpio/nrf5: set and clear just the specific gpio pin
- https://gerrit.zephyrproject.org/r/5252 : net: yaip: Refactor nbuf data fragment detection
- https://gerrit.zephyrproject.org/r/5251 : net: yaip: Re-order fields in net_nbuf struct
- https://gerrit.zephyrproject.org/r/5194 : stm32l4: add initial soc support for stm32l4
- https://gerrit.zephyrproject.org/r/5250 : net: yaip: Fix ND RA length
- https://gerrit.zephyrproject.org/r/5243 : net: yaip: Remove assert and return false
- https://gerrit.zephyrproject.org/r/5242 : net: tests: Add 6lo context based unit tests
- https://gerrit.zephyrproject.org/r/5240 : net: yaip: Add more inline helper functions in 6lowpan
- https://gerrit.zephyrproject.org/r/5228 : net: yaip: arp: Fix an issue with compiler optimization on Arduino 101
- https://gerrit.zephyrproject.org/r/5232 : driver: Fixed Atmel SAM3 serial driver.
- https://gerrit.zephyrproject.org/r/5230 : arduino 101: Exposes spi 0 in pinmux
- https://gerrit.zephyrproject.org/r/5209 : sensors: use one single sys log config for sensors
- https://gerrit.zephyrproject.org/r/5231 : arch/arm: add initial support for Cortex-M0/M0+
- https://gerrit.zephyrproject.org/r/5218 : arm: move atomic operations selection to the Cortex-M Kconfig
- https://gerrit.zephyrproject.org/r/5224 : unified: clean-up timeout code for unpending a thread
- https://gerrit.zephyrproject.org/r/5227 : unified: cleanup kernel initialization
- https://gerrit.zephyrproject.org/r/5212 : net: yaip: Small simplififcation to net_nbuf_write
- https://gerrit.zephyrproject.org/r/5219 : unified: have __ticks_to_ms() return 0 when no system clock
- https://gerrit.zephyrproject.org/r/5223 : unified: streamline "timeout add" internal interfaces.
- https://gerrit.zephyrproject.org/r/5226 : unified: remove last instances of struct tcs
- https://gerrit.zephyrproject.org/r/5222 : unified/mem_pool: use K_NO_WAIT, not TICKS_NONE
- https://gerrit.zephyrproject.org/r/5225 : unified: remaining timeout cleanup
- https://gerrit.zephyrproject.org/r/5221 : unified: streamline "timeout abort" internal interface
- https://gerrit.zephyrproject.org/r/5220 : unified/legacy: disable clock-based work_q APIs when no system clock
- https://gerrit.zephyrproject.org/r/5216 : flash/nrf5: support non word-aligned write
- https://gerrit.zephyrproject.org/r/5217 : samples/soc_flash_nrf5: test non-word aligned writes
- https://gerrit.zephyrproject.org/r/5215 : drivers/exti_stm32: fix clear pending exti
- https://gerrit.zephyrproject.org/r/5214 : exti/stm32: fix driver data handling
- https://gerrit.zephyrproject.org/r/5211 : drivers: gpio: i2c: make logging depend on SYS_LOG
- https://gerrit.zephyrproject.org/r/5210 : unified: move code from nanokernel into unified kernel
- https://gerrit.zephyrproject.org/r/5208 : arm: remove exc_wrapper.S
- https://gerrit.zephyrproject.org/r/5205 : stm32l4: add pinconf settings for I2C
- https://gerrit.zephyrproject.org/r/5201 : stm32lx: add u(s)art driver for the L series
- https://gerrit.zephyrproject.org/r/5200 : stm32l4: add pinconf for USARTs
- https://gerrit.zephyrproject.org/r/5206 : stm32lx: add i2c driver for the L series
- https://gerrit.zephyrproject.org/r/5207 : nucleo_l476rg: add board support
- https://gerrit.zephyrproject.org/r/5197 : stm32_exti: add support for controllers with more than 32 lines
- https://gerrit.zephyrproject.org/r/5199 : stm32l4: add pinmux for USARTs
- https://gerrit.zephyrproject.org/r/5198 : stm32l4: add exti support
- https://gerrit.zephyrproject.org/r/5196 : stm32l4: add gpio support for l4
- https://gerrit.zephyrproject.org/r/5203 : pinmux/stm32: add support for pinmux of port h
- https://gerrit.zephyrproject.org/r/5191 : net: Respect ether_type field.
- https://gerrit.zephyrproject.org/r/5204 : pinmux/stm32: add pinmux definition for i2c
- https://gerrit.zephyrproject.org/r/5202 : pinmux/stm32: add support for up to 16 alternate functions
- https://gerrit.zephyrproject.org/r/5195 : stm32l4: add clock control driver

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5118 : eth: Add KSDK ENET driver.
- https://gerrit.zephyrproject.org/r/5077 : net: yaip: Fix net_nbuf_read corner cases
- https://gerrit.zephyrproject.org/r/5183 : Bluetooth: tester: Rework discovery procedure
- https://gerrit.zephyrproject.org/r/5006 : enc28j60: Adapt driver for YAIP
- https://gerrit.zephyrproject.org/r/4795 : Bluetooth: L2CAP: Refactor handling connection response
- https://gerrit.zephyrproject.org/r/4796 : Bluetooth: L2CAP: Handle security procedure non successful path
- https://gerrit.zephyrproject.org/r/5190 : Bluetooth: IPSS: Make ipss_listen depend on CONFIG_NETWORKING_WITH_BT
- https://gerrit.zephyrproject.org/r/4917 : iot/zoap: Port to the new network stack
- https://gerrit.zephyrproject.org/r/5188 : Bluetooth: L2CAP: Fix sending buffer with not enough space
- https://gerrit.zephyrproject.org/r/5189 : Bluetooth: L2CAP: Allow sending fragmented buffers
- https://gerrit.zephyrproject.org/r/5175 : net:yaip: Solve style issues
- https://gerrit.zephyrproject.org/r/5051 : enc28j60: Modify echo server sample to support enc28j60
- https://gerrit.zephyrproject.org/r/5164 : enc28j60: Modify echo client sample to support enc28j60
- https://gerrit.zephyrproject.org/r/3312 : drivers/crypto: TinyCrypt shim driver
- https://gerrit.zephyrproject.org/r/3313 : samples/drivers/crypto: crypto sample app
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/5102 : unified: un-comment k_thread_[suspend|resume|abort_handler_set]
- https://gerrit.zephyrproject.org/r/5101 : dlist: add sys_dlist_peek_head_not_empty()
- https://gerrit.zephyrproject.org/r/5104 : unified: cache the next thread to run
- https://gerrit.zephyrproject.org/r/5103 : unified: use sys_dlist_peek_head_not_empty()
- https://gerrit.zephyrproject.org/r/5100 : unified/arm: fix saving of registers in __pendsv()
- https://gerrit.zephyrproject.org/r/4883 : sanity: enable sanity multiple configuration
- https://gerrit.zephyrproject.org/r/4635 : serial: make nrf5 driver more generic, prepare for nrf51
- https://gerrit.zephyrproject.org/r/4454 : net/yaip: Separate SLIP support into TAP and TUN options
- https://gerrit.zephyrproject.org/r/4455 : drivers/slip: Fix circular dependency on NET_SLIP
- https://gerrit.zephyrproject.org/r/5171 : samples/mbedtls_dtlsclient: mbedTLS sample DTLS client app.
- https://gerrit.zephyrproject.org/r/22 : ci: test: checkpatch: error braces
- https://gerrit.zephyrproject.org/r/5187 : net: dhcpv4: Adjust debug diagnostic wording.
- https://gerrit.zephyrproject.org/r/5186 : net: dhcpv4: Issue an NET_INFO when dhcpv4 allocates an IP.
- https://gerrit.zephyrproject.org/r/5184 : net: dhcpv4: Implement XID
- https://gerrit.zephyrproject.org/r/5185 : net: dhcpv4: Add received message debug.

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5229 : kernel: event logger needs ring buffer
- https://gerrit.zephyrproject.org/r/5236 : net: yaip: ethernet: Drop the packet early when relevant
- https://gerrit.zephyrproject.org/r/5237 : net: yaip: ethernet: Set ll_reserve only when ready
- https://gerrit.zephyrproject.org/r/5192 : sensors: do not use choice for I2C address
- https://gerrit.zephyrproject.org/r/5193 : stm32: make SRAM/FLASH base address generic to soc
- https://gerrit.zephyrproject.org/r/5160 : net: yaip: events: Fix a mix up between code and command
- https://gerrit.zephyrproject.org/r/5180 : net: yaip: Fix buffer leak in 6lowpan compression
- https://gerrit.zephyrproject.org/r/5182 : net: tests: Decrease the required buffers count
- https://gerrit.zephyrproject.org/r/5181 : net: yaip: Fix buffer leak in ieee802154 fragmentation
- https://gerrit.zephyrproject.org/r/5179 : sensors: HDC1000: check for manufacturer and device IDs
- https://gerrit.zephyrproject.org/r/4634 : drivers/gpio: nrf5: Use generic GPIO base naming
- https://gerrit.zephyrproject.org/r/5176 : samples: remove useless printf/printk wrappers
- https://gerrit.zephyrproject.org/r/5178 : sensors: use one init priority config for all sensors
- https://gerrit.zephyrproject.org/r/5173 : Bluetooth: Fix Kconfig typo
- https://gerrit.zephyrproject.org/r/5161 : Bluetooth: HCI: Add OpCode definition for setting page timeout
- https://gerrit.zephyrproject.org/r/4511 : unified/doc: Kernel primer for unified kernel


Re: Device driver configuration and driver_data distinction.

Andy Ross
 

Marcus Shawcroft wrote (on Thursday, October 06, 2016 8:26AM):
Andy, I think we are talking about to different structures
Ah, gotcha. Yeah, you're totally right. The only trick I can see
with merging this would be verifying that no existing drivers are
accidentally exploiting that missing const to mutate their config
structs.

Andy


Re: Device driver configuration and driver_data distinction.

Marcus Shawcroft <marcus.shawcroft@...>
 

On 6 October 2016 at 15:58, Andy Ross <andrew.j.ross(a)intel.com> wrote:
Marcus Shawcroft wrote (on Thursday, October 06, 2016 3:18AM):
This design make sense from the perspective that the read only config
data *could* be const and placed in flash only, hence lowering
pressure on sram.

However, it is not possible to make a drivers config structure const
because include/device.h defines struct device_config with a non const
*config_info
Actually it goes into the ROM data section anyway, despite the lack of
const. This is controlled in device.h by declaring the device_config
struct to be in the "devconfig.init" section. This then is placed by
the linker script (one per arhicecture right now, sigh) into the
ROMable region, right before the compiler-managed .rodata (which of
course *is* the stuff that depends on const).

The lack of const is (well, should be) just a missed opportunity for
compiler warnings. But AFAICT it's wrong and should be fixed.
Andy, I think we are talking about to different structures, given:

static struct gpio_k64_config gpio_k64_E_cfg = {
.gpio_base_addr = GPIO_K64_E_BASE_ADDR,
.port_base_addr = PORT_K64_E_BASE_ADDR,
};
DEVICE_AND_API_INIT(gpio_k64_E, CONFIG_GPIO_K64_E_DEV_NAME, gpio_k64_E_init,
&gpio_data_E, &gpio_k64_E_cfg,
SECONDARY, CONFIG_KERNEL_INIT_PRIORITY_DEFAULT,
&gpio_k64_drv_api_funcs);


The gpio_k64_E_cfg structure is placed in the data section and copied
to RAM from FLASH at startup.

2000007c l O datas 00000008 gpio_k64_E_cfg

Making in const (and dealing with the *config_info discussed above), gives:
00003b20 l O rodata 00000008 gpio_k64_E_cfg

Cheers
/Marcus


Re: Device driver configuration and driver_data distinction.

Andy Ross
 

Marcus Shawcroft wrote (on Thursday, October 06, 2016 3:18AM):
This design make sense from the perspective that the read only config
data *could* be const and placed in flash only, hence lowering
pressure on sram.

However, it is not possible to make a drivers config structure const
because include/device.h defines struct device_config with a non const
*config_info
Actually it goes into the ROM data section anyway, despite the lack of
const. This is controlled in device.h by declaring the device_config
struct to be in the "devconfig.init" section. This then is placed by
the linker script (one per arhicecture right now, sigh) into the
ROMable region, right before the compiler-managed .rodata (which of
course *is* the stuff that depends on const).

The lack of const is (well, should be) just a missed opportunity for
compiler warnings. But AFAICT it's wrong and should be fixed.

Andy


Re: Device driver configuration and driver_data distinction.

Jon Medhurst (Tixy) <tixy@...>
 

On Thu, 2016-10-06 at 11:18 +0100, Marcus Shawcroft wrote:
The DEVICE_INIT() macro and associated driver framework provides for
each driver instance to have two data structures, the config structure
and the driver_data structure.

Documentation in docs/drivers/drivers.rst indicates that the
configuration structure is for read only, build time configured data,
while the driver_data structure is for dynamic state.

This design make sense from the perspective that the read only config
data *could* be const and placed in flash only, hence lowering
pressure on sram.

However, it is not possible to make a drivers config structure const
because include/device.h defines struct device_config with a non const
*config_info, hence passing a const config structure to DEVICE_INIT()
generates a diagnostic/error.
I too wondered the same, as my first instinct was to declare these const
along with other structures like the various API function tables and
strings used for device names. But the compiler soon alerted me to the
fact that Zephy APIs seem to have an allergy to 'const' :-)

I don't know if the widespread use of sections and linker scripts
actually ends up putting a lot of these things into read-only memory
anyway, or if these all really do end up wasting RAM.

--
Tixy


Re: RFC: Energy Management Support in Zephyr

Marcus Shawcroft <marcus.shawcroft@...>
 

On 6 October 2016 at 11:42, Chakravarty, Souvik K
<souvik.k.chakravarty(a)intel.com> wrote:

Hi,

Good to see someone working on an energy management platform API. I
don;t have strong opinions on the organization of the proposed API,
the proposal looks sensible to me.

The restriction to microkernel seems odd, there is nothing proposed
here that looks difficult/awkward or inappropriate for nano kernel.
Are there specific reason you exclude nano ?

Below are some nit pick comments:

A common theme is the provision of _unknown_ enums values. Providing
an unknown or catchall enum is sometimes necessary because it is clear
that legitimate cases exist that are not covered by the other specific
enums. For example it would be quite reasonable for a driver to be
able to report that a battery is connected, disconnected, or it is
unknown. But, providing "unknowns" in other situations can be
undesirable for a couple of reasons.
- Consider a driver that needs to report something to the application,
but the API designer did not forsee a specific event. The driver
writer has two options a) fudge it and report "unknown", b) Extend the
API to include the missing specific event. If we provide "unknown" we
encourage behaviour a) but ideally we want to encourage behaviour b).
- Consider a driver that is asked to perform some action against an
"unknown" entity, what should it do? (In this case what does it mean
for an application to ask for the sampling interval to be set for an
"unknown" entity).
- Consider an application that receives an "unknown" event
notification. It can't do anything meaningful with such an event
unless there is some implied semantic associated with the event, in
which case unknown is not an appropriate name.

In this API, it looks to me that a number of the "unknown" enums, are
undesirable. I'm interested to understand any concrete use cases we
have in mind that warrants inclusion of such "unknown" enums.

+enum em_notifier_type {
+ EM_NOTIFY_CHARGER_DISCONNECTED,
+ EM_NOTIFY_CHARGER_CONNECTED,
+ EM_NOTIFY_BATT_LEVEL_CHANGED,
+ EM_MOTIFY_BATT_TEMP_SHUTDOWN,
+ EM_NOTIFY_BATT_TEMP_CRIT,
+ EM_NOTIFY_BATT_SHUTDOWN,
+ EM_NOTIFY_BATT_FULL,
+ EM_NOTIFY_BATT_LOW,
+ EM_NOTIFY_BATT_CRIT,
+ EM_NOTIFY_UNKNOWN

This unknown looks questionable to me. An application cannot do
anything meaningful with an "unknown energy management" event.

+/** Possible entities which can be sampled: Fuel-Gauge or Temperature. */
+enum em_sample_type {
+ EM_SAMPLE_FG,
+ EM_SAMPLE_TEMP,
+ EM_SAMPLE_UNKNOWN
+};

This one also looks questionable, it doesn;t make sense to ask a
driver to sample an unknown entity.

+/** Status: Whether Charging or Discharging. */
+enum em_charging_status {
+ EM_DISCHARGING,
+ EM_MAINTANENCE,
+ EM_CHARGING,
+ EM_UNKNOWN
This unknown would seem reasonable, it is conceivable that a platform
has no idea if it is charging or not.

What would EM_MAINTENANCE signify?


+/** Information regarding the charging status of the platform */
+struct em_charging_stat {
+ /** Charger connected status: 0 - Disconnected, 1 - Connected */
+ bool charger_status;
The use of bool here requires that a driver can detected the presence
of a charger. I doubt that is always the case in all devices that we
might be deployed on.

+bool em_batt_present(void);
Similarly, bool here suggests that every platform can answer the
question with true or false, but it seems plausible to me that not all
platforms will have the HW to answer that question.

+
+/**
+ * @brief Get the battery terminal voltage
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param volt pointer to voltage of the battery in mV
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_voltage_get(int8_t *volt);
We should list the error codes that can be returned by these
functions. Especially interesting is the appropriate error code for
"unknown".

+int32_t em_batt_charge_thresholds_set(struct em_batt_charge_thresholds
+ thresholds);
+
* missing ?


+int32_t em_batt_temperature_thresholds_set(struct
+ em_batt_temperature_thresholds thresholds);
* missing ?


Many of the API function parameters proposed could be "const".

Cheers
/Marcus


Re: RFC: Energy Management Support in Zephyr

Tomasz Bursztyka
 

Hi Souvik,

Hello everybody,

I have been looking into the aspects of Charging & Battery Management in Zephyr (aka Energy Management) via ZEP-1037.

I find that there is no standard interface or framework defined. This means that one needs to know the complete details of the platform below before even starting to get an Energy Management application going. Hence third-party applications made for one platform will not necessarily be usable elsewhere. This is not very user friendly & increases software costs. Fundamentally one should be able to fetch, via a standard mechanism, simple details like, if the platform supports a battery, what is the battery charge level & get some notifications, without bothering about the platform details below.
(As an aside if Zephyr is used inside a device used for an application that drains out the battery every few weeks, e.g. a wearable, you need to support charging.)

I propose to have a lightweight standard set of Energy Management Interface APIs that any application can use. The implementation of these APIs is done by the platform specific drivers below. This will be just be a set of interface APIs, which can function in the caller context.

Currently we can target this to work with microkernel systems. For nanokernel systems, battery management seems an overkill (I am however open to review my stance here).
I don't see why it would be too heavy for nanokernel.
At least I don't see any reason to opt-out nanokernel support from the
design.

This Energy Management API framework should enable applications to do the following in a standard manner (the feature set can be expanded later if desired)
1) Get notified on Battery threshold breach & Charger Events.
2) Configure the battery charge & temperature level thresholds for callback notifications: Warning, Critical, Shutdown
3) Enable/disable charging
4) Fix the sampling rate for Charge and Battery Temperature measurement to be done by the drivers below
5) Get Battery Terminal Voltage, Temperature, State Of Charge (SOC) - %
The implementation of these APIs is left to the Fuel-Gauging & Charging drivers. These APIs are stubbed and designed to return an error code when charging & FG drivers are not present.
I think all these could be part of, or use, Sensor API. See below


The immediate benefit is that the user or application no longer has to depend upon gory device driver specific details just for fetching stuff like "does my device have a battery, how much is its charge level" etc.
In the longer term, any third party device manufacturer can have their own standard application for managing the battery that works out of the box on any device running Zephyr.

I have hashed out a set of basic APIs below. The guiding principle in this has been to keep it very light & flexible. I intend to upload the implementation for review once comments are incorporated.

Let me know your comments, esp. on implementing Point 1 above (how to get notifications to the application). I was thinking of callback to the user from a fiber context in the FG/Charger drivers (that the application can offload).
I also thought about using a Private Semaphore group with the Semaphores defined by this framework but decided against it, because that would require the application to handle this in a task context and handling can be delayed (remember some of these notifications are urgent and delayed-action could do some damage...like battery overheating/Charge becoming dangerously low etc.).
Is it a better approach to use events (defined in the Interface API) for each Notification type, with the application setting the Event Handler (uses Microkernel Server Fiber) and the events being signaled from the drivers?

energy_management/energy_management.h | 411 ++++++++++++++++++++++++++++++++++
1 file changed, 411 insertions(+)
create mode 100644 energy_management/energy_management.h

diff --git a/energy_management/energy_management.h b/energy_management/energy_management.h
new file mode 100644
index 0000000..22c4331
--- /dev/null
+++ b/energy_management/energy_management.h
@@ -0,0 +1,411 @@
+
+/**
+ * @file
+ * @brief Specifies the Energy Management Framework APIs.
+ *
+ * @details Specifies the standard Energy Management Interface APIs for Zephyr.
+ * These APIs will be used by applications for interacting & controlling the
+ * Battery Charger and the Fuel Gauge subsystems. This enables applications to
+ * use a standard interface while the platform level details are abstracted.
+ *
+ * The APIs should be implemented by the Fuel Gauge & Charging driver framework .
+ * Default implementation is stubbed.
+ * _________________
+ * | |
+ * | APPLICATIONS |
+ * |_________________|
+ * |
+ * |
+ * V
+ * ------ EM INTERFACE APIs ---------
+ * |
+ * |
+ * ____________V__________
+ * | |
+ * | Charging & FG drivers |
+ * |_______________________|
+ *
+ */
+
+/*---------------------------------------------------------------------------
+ * Object Declarations
+ *---------------------------------------------------------------------------
+ */
+
+/** EM Notification types that can be received by the application. */
+enum em_notifier_type {
+ EM_NOTIFY_CHARGER_DISCONNECTED,
+ EM_NOTIFY_CHARGER_CONNECTED,
+ EM_NOTIFY_BATT_LEVEL_CHANGED,
+ EM_MOTIFY_BATT_TEMP_SHUTDOWN,
+ EM_NOTIFY_BATT_TEMP_CRIT,
+ EM_NOTIFY_BATT_SHUTDOWN,
+ EM_NOTIFY_BATT_FULL,
+ EM_NOTIFY_BATT_LOW,
+ EM_NOTIFY_BATT_CRIT,
+ EM_NOTIFY_UNKNOWN
+};
+
+/** Possible entities which can be sampled: Fuel-Gauge or Temperature. */
+enum em_sample_type {
+ EM_SAMPLE_FG,
+ EM_SAMPLE_TEMP,
+ EM_SAMPLE_UNKNOWN
+};
Have you considered sensor API? At least for the low level part (driver
related)
To me it sounds it could fully fit there. You would need a new sensor
channels: battery gauge, battery status... or
something like that, etc...

Temperature exists already.

So a battery controller driver would expose relevant sensor channels.

+
+/** The possible charger type connected to the device. */
+enum em_charger_type {
+ EM_CHARGER_NONE,
+ EM_CHARGER_WALL,
+ EM_CHARGER_USB,
+ EM_CHARGER_WIRELESS,
+ EM_CHARGER_UNKNOWN
+};
Are you sure this would be needed?

+
+/** Status: Whether Charging or Discharging. */
+enum em_charging_status {
+ EM_DISCHARGING,
+ EM_MAINTANENCE,
+ EM_CHARGING,
+ EM_UNKNOWN
+};
Again, sensor API provide trigger capabilities. So battery controller
driver could
use this.

+
+/**
+ * @brief Defines the three charge level thresholds in % SOC.
+ *
+ * Notifications generated when battery falls below each of the thresholds.
+ *
+ * @param shutdown Threshold at which the platform will be shut down
+ * as battery charge is insufficient.
+ * @param critical Platform should be prepared for impending shutdown.
+ * Recharge ASAP.
+ * @param low Battery should be recharged ASAP to keep system functional.
+ */
+struct em_batt_charge_thresholds {
+ uint8_t shutdown;
+ uint8_t crit;
+ uint8_t low;
+};
I am not sure you want to make these user land modified.
On embedded use case, things are crafted per-board, per-devices, so
these could be made
Kconfig based, or board.h or soc.h. But no need to let the application
side messing up with it.

+
+/**
+ * @brief Defines the two temperature level thresholds in Degree Celcius.
+ *
+ * Notification generated when battery pack temperature rises above each of
+ * these thresholds.
+ *
+ * @param Shutdown Temperature at which the system should be shutdown
+ * to prevent fatal or permanent damage.
+ * @param Critical Charging should be stopped to prevent further temp rise.
+ * Charging becomes unsafe at this temperature.
+ */
+struct em_batt_temperature_thresholds {
+ uint8_t shutdown;
+ uint8_t crit;
+};
Same as above.

+
+/** Information regarding the charging status of the platform */
+struct em_charging_stat {
+ /** Charger connected status: 0 - Disconnected, 1 - Connected */
+ bool charger_status;
+
+ enum em_charger_type chgr_type;
+ enum em_charging_status charging_status;
+};
+
+/**
+ * @typedef em_notifier_t
+ * @brief Callback API notified when a charger or FG event occurs.
+ *
+ * @param type The type of Notification that has arrived
+ * @param data Any Notification specific data to be interpreted by application
+ */
+typedef int32_t (*em_notifier_t)(enum em_notifier_type type, void *data);
+
+
+/*----------------------------------------------------------------------------
+ * EM Interface APIs
+ *----------------------------------------------------------------------------
+ */
+
+/**
+ * @brief Query if Battery is present
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param N/A
+ *
+ * @return true if battery is present and false otherwise
+ */
+bool em_batt_present(void);
+
+/**
+ * @brief Get the battery terminal voltage
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param volt pointer to voltage of the battery in mV
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_voltage_get(int8_t *volt);
+
+/**
+ * @brief Get the battery-pack temperature
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param temp pointer to temperature of the battery-pack in degree Centigrade
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_temperature_get(int16_t *temp);
+
+/**
+ * @brief Get the battery State of Charge (SOC)
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param soc pointer to Charge remaining on Battery in %
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_soc_get(int8_t *soc);
+
+/**
+ * @brief Set the battery sampling interval
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param interval Interval of sampling in ms
+ * @param type Type of Sample (Temperature/Charge)
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_sampling_interval_set(int16_t interval,
+ enum em_sample_type type);
+
+/**
+ * @brief Get the battery sampling interval
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param interval Pointer to interval of sampling in ms
+ * @param type Type of Sample (Temperature/Charge)
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_sampling_interval_get(int16_t *interval,
+ enum em_sample_type type);
+
+/**
+ * @brief Get the number of configurable battery charge thresholds
+ *
+ * Get the number of battery charge thresholds that can be configured.
+ * When the battery charge level falls below each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 3 (Warning, Critical & Shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param num Pointer indicating no. of thresholds that can be configured
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_num_charge_thresholds_get(int8_t *num);
+
+/**
+ * @brief Get the battery charge thresholds settings
+ *
+ * Get the battery charge thresholds that are currently set.
+ * When the battery charge level falls below each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 3 (Warning, Critical & Shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param thresholds pointer to structure (each field is indicated in % charge)
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_charge_thresholds_get(struct em_batt_charge_thresholds
+ *thresholds);
+
+/**
+ * @brief Set the battery charge thresholds
+ *
+ * Trying to set more levels than permissible (returned by
+ * em_batt_charge_thresholds_get) is not allowed.
+ * When the battery charge level falls below each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 3 (Warning, Critical & Shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param thresholds Each field indicates values in % of charge
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_charge_thresholds_set(struct em_batt_charge_thresholds
+ thresholds);
+
+/**
+ * @brief Get the number of configurable battery temperature thresholds
+ *
+ * Get the number of battery temperature thresholds that can be configured.
+ * When the battery temperature rises above each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 2 (Critical & shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param num Pointer indicating no. of thresholds that can be configured
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_num_temperature_thresholds_get(int8_t *num);
+
+/**
+ * @brief Get the battery temperature thresholds configured
+ *
+ * When the battery temperature rises above each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 2 (Critical & shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param thresholds pointer to structure (each field is indicated in Celsius)
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_temperature_thresholds_get(struct
+ em_batt_temperature_thresholds
+ *thresholds);
+
+/**
+ * @brief Set the battery temperature thresholds
+ *
+ * Trying to set more levels than permissible (returned by
+ * em_batt_num_temperature_thresholds_get) is not allowed.
+ * When the battery temperature rises above each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 2 (Critical & shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param thresholds to set. Each field indicates values in degree centigrade
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_temperature_thresholds_set(struct
+ em_batt_temperature_thresholds thresholds);
+
+/**
+ * @brief Disable Battery Charging
+ *
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param N/A
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_charging_disable(void);
+
+/**
+ * @brief Enable Battery Charging
+ *
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param N/A
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_charging_enable(void);
+
+/**
+ * @brief Get the Charging Status
+ *
+ * Gives the following information:
+ * 1) Charger is connected or disconnected
+ * 2) Charger Type: Wall/USB/Wireless
+ * 3) Charging Status: Charging/Discharging/Maintenance Charging
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param status pointer to struct containing the status
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_charging_get_status(struct em_charging_stat *status);
+
+/**
+ * @brief Register for a Notifier with the Driver Subsystem
+ *
+ * Notifier will get called whenever an event occurs.
+ * Calling may happen at fiber context so it is important that the callee
+ * does not undertake long duration work in same context. In case any long
+ * duration work is needed to be done, offloading using from fiber context
+ * using events etc. is recommended.
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param notifier
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_register_notifier(struct em_notifier_t notifier); /* Assumes Callback implementation */
+
--
2.7.4


Re: Device driver configuration and driver_data distinction.

Tomasz Bursztyka
 

Hi Marcus,

I believe we did not make it const at the beginning due to PCI
enumeration on Galileo.
This was early days, and things changed then.

Actually there have been plans to move it to const, at least I remember
hearing such idea
from Daniel Kalowsky, for the same exact reasons you noted, it might
even be in the git history,
somewhere. But we were too busy to follow up at that time.

So this would indeed be very welcome, if you want to propose a patch for it.
Note, however, that some device drivers may be using such configuration
structure wrongly.
(aka: accessing and changing its data). So you would probably need to
change things there as well.

Tomasz

Hi,

The DEVICE_INIT() macro and associated driver framework provides for
each driver instance to have two data structures, the config structure
and the driver_data structure.

Documentation in docs/drivers/drivers.rst indicates that the
configuration structure is for read only, build time configured data,
while the driver_data structure is for dynamic state.

This design make sense from the perspective that the read only config
data *could* be const and placed in flash only, hence lowering
pressure on sram.

However, it is not possible to make a drivers config structure const
because include/device.h defines struct device_config with a non const
*config_info, hence passing a const config structure to DEVICE_INIT()
generates a diagnostic/error.

I can see no obvious reason why we do not define config_info as const
paving the way for device config information to move to flash.

The infrastructure around config_info was landed in:
commit c9ac95a43aa46e0714a8db10d4d8f940c952acaf
Author: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

config_info was non const in this original commit.

Can anybody provide insight into why config_info should not be const?
Was this an oversight, or, by design, in the original implementation?

Cheers
/Marcus


RFC: Energy Management Support in Zephyr

Chakravarty, Souvik K
 

Hello everybody,

I have been looking into the aspects of Charging & Battery Management in Zephyr (aka Energy Management) via ZEP-1037.

I find that there is no standard interface or framework defined. This means that one needs to know the complete details of the platform below before even starting to get an Energy Management application going. Hence third-party applications made for one platform will not necessarily be usable elsewhere. This is not very user friendly & increases software costs. Fundamentally one should be able to fetch, via a standard mechanism, simple details like, if the platform supports a battery, what is the battery charge level & get some notifications, without bothering about the platform details below.
(As an aside if Zephyr is used inside a device used for an application that drains out the battery every few weeks, e.g. a wearable, you need to support charging.)

I propose to have a lightweight standard set of Energy Management Interface APIs that any application can use. The implementation of these APIs is done by the platform specific drivers below. This will be just be a set of interface APIs, which can function in the caller context.

Currently we can target this to work with microkernel systems. For nanokernel systems, battery management seems an overkill (I am however open to review my stance here).

This Energy Management API framework should enable applications to do the following in a standard manner (the feature set can be expanded later if desired)
1) Get notified on Battery threshold breach & Charger Events.
2) Configure the battery charge & temperature level thresholds for callback notifications: Warning, Critical, Shutdown
3) Enable/disable charging
4) Fix the sampling rate for Charge and Battery Temperature measurement to be done by the drivers below
5) Get Battery Terminal Voltage, Temperature, State Of Charge (SOC) - %
The implementation of these APIs is left to the Fuel-Gauging & Charging drivers. These APIs are stubbed and designed to return an error code when charging & FG drivers are not present.

The immediate benefit is that the user or application no longer has to depend upon gory device driver specific details just for fetching stuff like "does my device have a battery, how much is its charge level" etc.
In the longer term, any third party device manufacturer can have their own standard application for managing the battery that works out of the box on any device running Zephyr.

I have hashed out a set of basic APIs below. The guiding principle in this has been to keep it very light & flexible. I intend to upload the implementation for review once comments are incorporated.

Let me know your comments, esp. on implementing Point 1 above (how to get notifications to the application). I was thinking of callback to the user from a fiber context in the FG/Charger drivers (that the application can offload).
I also thought about using a Private Semaphore group with the Semaphores defined by this framework but decided against it, because that would require the application to handle this in a task context and handling can be delayed (remember some of these notifications are urgent and delayed-action could do some damage...like battery overheating/Charge becoming dangerously low etc.).
Is it a better approach to use events (defined in the Interface API) for each Notification type, with the application setting the Event Handler (uses Microkernel Server Fiber) and the events being signaled from the drivers?

energy_management/energy_management.h | 411 ++++++++++++++++++++++++++++++++++
1 file changed, 411 insertions(+)
create mode 100644 energy_management/energy_management.h

diff --git a/energy_management/energy_management.h b/energy_management/energy_management.h
new file mode 100644
index 0000000..22c4331
--- /dev/null
+++ b/energy_management/energy_management.h
@@ -0,0 +1,411 @@
+
+/**
+ * @file
+ * @brief Specifies the Energy Management Framework APIs.
+ *
+ * @details Specifies the standard Energy Management Interface APIs for Zephyr.
+ * These APIs will be used by applications for interacting & controlling the
+ * Battery Charger and the Fuel Gauge subsystems. This enables applications to
+ * use a standard interface while the platform level details are abstracted.
+ *
+ * The APIs should be implemented by the Fuel Gauge & Charging driver framework .
+ * Default implementation is stubbed.
+ * _________________
+ * | |
+ * | APPLICATIONS |
+ * |_________________|
+ * |
+ * |
+ * V
+ * ------ EM INTERFACE APIs ---------
+ * |
+ * |
+ * ____________V__________
+ * | |
+ * | Charging & FG drivers |
+ * |_______________________|
+ *
+ */
+
+/*---------------------------------------------------------------------------
+ * Object Declarations
+ *---------------------------------------------------------------------------
+ */
+
+/** EM Notification types that can be received by the application. */
+enum em_notifier_type {
+ EM_NOTIFY_CHARGER_DISCONNECTED,
+ EM_NOTIFY_CHARGER_CONNECTED,
+ EM_NOTIFY_BATT_LEVEL_CHANGED,
+ EM_MOTIFY_BATT_TEMP_SHUTDOWN,
+ EM_NOTIFY_BATT_TEMP_CRIT,
+ EM_NOTIFY_BATT_SHUTDOWN,
+ EM_NOTIFY_BATT_FULL,
+ EM_NOTIFY_BATT_LOW,
+ EM_NOTIFY_BATT_CRIT,
+ EM_NOTIFY_UNKNOWN
+};
+
+/** Possible entities which can be sampled: Fuel-Gauge or Temperature. */
+enum em_sample_type {
+ EM_SAMPLE_FG,
+ EM_SAMPLE_TEMP,
+ EM_SAMPLE_UNKNOWN
+};
+
+/** The possible charger type connected to the device. */
+enum em_charger_type {
+ EM_CHARGER_NONE,
+ EM_CHARGER_WALL,
+ EM_CHARGER_USB,
+ EM_CHARGER_WIRELESS,
+ EM_CHARGER_UNKNOWN
+};
+
+/** Status: Whether Charging or Discharging. */
+enum em_charging_status {
+ EM_DISCHARGING,
+ EM_MAINTANENCE,
+ EM_CHARGING,
+ EM_UNKNOWN
+};
+
+/**
+ * @brief Defines the three charge level thresholds in % SOC.
+ *
+ * Notifications generated when battery falls below each of the thresholds.
+ *
+ * @param shutdown Threshold at which the platform will be shut down
+ * as battery charge is insufficient.
+ * @param critical Platform should be prepared for impending shutdown.
+ * Recharge ASAP.
+ * @param low Battery should be recharged ASAP to keep system functional.
+ */
+struct em_batt_charge_thresholds {
+ uint8_t shutdown;
+ uint8_t crit;
+ uint8_t low;
+};
+
+/**
+ * @brief Defines the two temperature level thresholds in Degree Celcius.
+ *
+ * Notification generated when battery pack temperature rises above each of
+ * these thresholds.
+ *
+ * @param Shutdown Temperature at which the system should be shutdown
+ * to prevent fatal or permanent damage.
+ * @param Critical Charging should be stopped to prevent further temp rise.
+ * Charging becomes unsafe at this temperature.
+ */
+struct em_batt_temperature_thresholds {
+ uint8_t shutdown;
+ uint8_t crit;
+};
+
+/** Information regarding the charging status of the platform */
+struct em_charging_stat {
+ /** Charger connected status: 0 - Disconnected, 1 - Connected */
+ bool charger_status;
+
+ enum em_charger_type chgr_type;
+ enum em_charging_status charging_status;
+};
+
+/**
+ * @typedef em_notifier_t
+ * @brief Callback API notified when a charger or FG event occurs.
+ *
+ * @param type The type of Notification that has arrived
+ * @param data Any Notification specific data to be interpreted by application
+ */
+typedef int32_t (*em_notifier_t)(enum em_notifier_type type, void *data);
+
+
+/*----------------------------------------------------------------------------
+ * EM Interface APIs
+ *----------------------------------------------------------------------------
+ */
+
+/**
+ * @brief Query if Battery is present
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param N/A
+ *
+ * @return true if battery is present and false otherwise
+ */
+bool em_batt_present(void);
+
+/**
+ * @brief Get the battery terminal voltage
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param volt pointer to voltage of the battery in mV
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_voltage_get(int8_t *volt);
+
+/**
+ * @brief Get the battery-pack temperature
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param temp pointer to temperature of the battery-pack in degree Centigrade
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_temperature_get(int16_t *temp);
+
+/**
+ * @brief Get the battery State of Charge (SOC)
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param soc pointer to Charge remaining on Battery in %
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_soc_get(int8_t *soc);
+
+/**
+ * @brief Set the battery sampling interval
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param interval Interval of sampling in ms
+ * @param type Type of Sample (Temperature/Charge)
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_sampling_interval_set(int16_t interval,
+ enum em_sample_type type);
+
+/**
+ * @brief Get the battery sampling interval
+ *
+ * Called by the application & implemented by the platform drivers
+ *
+ * @param interval Pointer to interval of sampling in ms
+ * @param type Type of Sample (Temperature/Charge)
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_sampling_interval_get(int16_t *interval,
+ enum em_sample_type type);
+
+/**
+ * @brief Get the number of configurable battery charge thresholds
+ *
+ * Get the number of battery charge thresholds that can be configured.
+ * When the battery charge level falls below each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 3 (Warning, Critical & Shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param num Pointer indicating no. of thresholds that can be configured
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_num_charge_thresholds_get(int8_t *num);
+
+/**
+ * @brief Get the battery charge thresholds settings
+ *
+ * Get the battery charge thresholds that are currently set.
+ * When the battery charge level falls below each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 3 (Warning, Critical & Shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param thresholds pointer to structure (each field is indicated in % charge)
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_charge_thresholds_get(struct em_batt_charge_thresholds
+ *thresholds);
+
+/**
+ * @brief Set the battery charge thresholds
+ *
+ * Trying to set more levels than permissible (returned by
+ * em_batt_charge_thresholds_get) is not allowed.
+ * When the battery charge level falls below each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 3 (Warning, Critical & Shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param thresholds Each field indicates values in % of charge
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_charge_thresholds_set(struct em_batt_charge_thresholds
+ thresholds);
+
+/**
+ * @brief Get the number of configurable battery temperature thresholds
+ *
+ * Get the number of battery temperature thresholds that can be configured.
+ * When the battery temperature rises above each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 2 (Critical & shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param num Pointer indicating no. of thresholds that can be configured
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_num_temperature_thresholds_get(int8_t *num);
+
+/**
+ * @brief Get the battery temperature thresholds configured
+ *
+ * When the battery temperature rises above each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 2 (Critical & shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param thresholds pointer to structure (each field is indicated in Celsius)
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_temperature_thresholds_get(struct
+ em_batt_temperature_thresholds
+ *thresholds);
+
+/**
+ * @brief Set the battery temperature thresholds
+ *
+ * Trying to set more levels than permissible (returned by
+ * em_batt_num_temperature_thresholds_get) is not allowed.
+ * When the battery temperature rises above each of these thresholds,
+ * an interrupt or callback is generated to the user to take actions.
+ * Max levels are 2 (Critical & shutdown)
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param thresholds to set. Each field indicates values in degree centigrade
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_batt_temperature_thresholds_set(struct
+ em_batt_temperature_thresholds thresholds);
+
+/**
+ * @brief Disable Battery Charging
+ *
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param N/A
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_charging_disable(void);
+
+/**
+ * @brief Enable Battery Charging
+ *
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param N/A
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_charging_enable(void);
+
+/**
+ * @brief Get the Charging Status
+ *
+ * Gives the following information:
+ * 1) Charger is connected or disconnected
+ * 2) Charger Type: Wall/USB/Wireless
+ * 3) Charging Status: Charging/Discharging/Maintenance Charging
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param status pointer to struct containing the status
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_charging_get_status(struct em_charging_stat *status);
+
+/**
+ * @brief Register for a Notifier with the Driver Subsystem
+ *
+ * Notifier will get called whenever an event occurs.
+ * Calling may happen at fiber context so it is important that the callee
+ * does not undertake long duration work in same context. In case any long
+ * duration work is needed to be done, offloading using from fiber context
+ * using events etc. is recommended.
+ * Called by the application & implemented by the platform drivers.
+ *
+ * @param notifier
+ *
+ * @return 0 if success, negative error code for error
+ */
+int32_t em_register_notifier(struct em_notifier_t notifier); /* Assumes Callback implementation */
+
--
2.7.4


Device driver configuration and driver_data distinction.

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi,

The DEVICE_INIT() macro and associated driver framework provides for
each driver instance to have two data structures, the config structure
and the driver_data structure.

Documentation in docs/drivers/drivers.rst indicates that the
configuration structure is for read only, build time configured data,
while the driver_data structure is for dynamic state.

This design make sense from the perspective that the read only config
data *could* be const and placed in flash only, hence lowering
pressure on sram.

However, it is not possible to make a drivers config structure const
because include/device.h defines struct device_config with a non const
*config_info, hence passing a const config structure to DEVICE_INIT()
generates a diagnostic/error.

I can see no obvious reason why we do not define config_info as const
paving the way for device config information to move to flash.

The infrastructure around config_info was landed in:
commit c9ac95a43aa46e0714a8db10d4d8f940c952acaf
Author: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

config_info was non const in this original commit.

Can anybody provide insight into why config_info should not be const?
Was this an oversight, or, by design, in the original implementation?

Cheers
/Marcus


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 4
[ZEP-1032] IPSP router role support
https://jira.zephyrproject.org/browse/ZEP-1032

[ZEP-1035] Utilizing QMSI driver to transceive over SPI back to back gives system crash
https://jira.zephyrproject.org/browse/ZEP-1035

[ZEP-1034] tests/bluetooth/shell/test_br does not fit `ROM' region with DEBUG on
https://jira.zephyrproject.org/browse/ZEP-1034

[ZEP-1033] tests/bluetooth/init/test_17 does not fit `FLASH' region with asserts on
https://jira.zephyrproject.org/browse/ZEP-1033


UPDATED JIRA items within last 24 hours: 8
[ZEP-916] Eliminate kernel object API anomalies
https://jira.zephyrproject.org/browse/ZEP-916

[ZEP-917] Add abort handler support
https://jira.zephyrproject.org/browse/ZEP-917

[ZEP-924] Revise documentation for Interrupts
https://jira.zephyrproject.org/browse/ZEP-924

[ZEP-923] Revise documentation for Timing
https://jira.zephyrproject.org/browse/ZEP-923

[ZEP-929] Verify the preempt-thread-only and coop-thread-only configurations
https://jira.zephyrproject.org/browse/ZEP-929

[ZEP-933] ARC port
https://jira.zephyrproject.org/browse/ZEP-933

[ZEP-989] Cache next ready thread instead of finding out the long way
https://jira.zephyrproject.org/browse/ZEP-989

[ZEP-578] handle configuration changes with more code coverage
https://jira.zephyrproject.org/browse/ZEP-578


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 4
[ZEP-914] (Won't Do) Improving locking algorithms in kernel objects
https://jira.zephyrproject.org/browse/ZEP-914

[ZEP-913] (Won't Do) Place thread stacks in their own linker section
https://jira.zephyrproject.org/browse/ZEP-913

[ZEP-1025] (Fixed) Unified kernel build sometimes breaks on a missing .d dependency file.
https://jira.zephyrproject.org/browse/ZEP-1025

[ZEP-1031] (Fixed) qmsi: dma: driver test fails with LLVM
https://jira.zephyrproject.org/browse/ZEP-1031


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/5190 : Bluetooth: IPSS: Make ipss_listen depend on CONFIG_NETWORKING_WITH_BT
- https://gerrit.zephyrproject.org/r/5189 : Bluetooth: L2CAP: Allow sending fragmented buffers
- https://gerrit.zephyrproject.org/r/5188 : Bluetooth: L2CAP: Fix sending buffer with not enough space
- https://gerrit.zephyrproject.org/r/5178 : sensors: use one init priority config for all sensors
- https://gerrit.zephyrproject.org/r/5177 : sensors: simplify kconfig for hdc100x sensor
- https://gerrit.zephyrproject.org/r/5179 : sensors: HDC1000: check for manufacturer and device IDs
- https://gerrit.zephyrproject.org/r/5176 : samples: remove useless printf/printk wrappers
- https://gerrit.zephyrproject.org/r/5173 : Bluetooth: Fix Kconfig typo
- https://gerrit.zephyrproject.org/r/5183 : Bluetooth: tester: Rework discovery procedure
- https://gerrit.zephyrproject.org/r/5187 : net: dhcpv4: Adjust debug diagnostic wording.
- https://gerrit.zephyrproject.org/r/5186 : net: dhcpv4: Issue an NET_INFO when dhcpv4 allocates an IP.
- https://gerrit.zephyrproject.org/r/5185 : net: dhcpv4: Add received message debug.
- https://gerrit.zephyrproject.org/r/5184 : net: dhcpv4: Implement XID
- https://gerrit.zephyrproject.org/r/5181 : net: yaip: Fix buffer leak in ieee802154 fragmentation
- https://gerrit.zephyrproject.org/r/5182 : net: tests: Decrease the required buffers count
- https://gerrit.zephyrproject.org/r/5180 : net: yaip: Fix buffer leak in 6lowpan compression
- https://gerrit.zephyrproject.org/r/5175 : net:yaip: Solve style issues
- https://gerrit.zephyrproject.org/r/5171 : samples/mbedtls_dtlsclient: mbedTLS sample DTLS client app.

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5118 : eth: Add KSDK ENET driver.
- https://gerrit.zephyrproject.org/r/5161 : Bluetooth: HCI: Add OpCode definition for setting page timeout
- https://gerrit.zephyrproject.org/r/4796 : Bluetooth: L2CAP: Handle security procedure non successful path
- https://gerrit.zephyrproject.org/r/4795 : Bluetooth: L2CAP: Refactor handling connection response
- https://gerrit.zephyrproject.org/r/4917 : iot/zoap: Port to the new network stack
- https://gerrit.zephyrproject.org/r/4562 : Bluetooth: Sample: handsfree sample application
- https://gerrit.zephyrproject.org/r/4282 : net: fetch valid conn. to determine MSS in data_is_sent_and_acked()
- https://gerrit.zephyrproject.org/r/5107 : samples: button: modify sample to work on more boards
- https://gerrit.zephyrproject.org/r/4555 : Bluetooth: HFP HF: SLC connection-Send/Parse BRSF
- https://gerrit.zephyrproject.org/r/5106 : boards: define user buttons and switches on boards
- https://gerrit.zephyrproject.org/r/4706 : net: fix a potential refcount leak of SYN buffers
- https://gerrit.zephyrproject.org/r/4808 : Bluetooth: L2CAP: Limit user I/O actions timeout in GAP context
- https://gerrit.zephyrproject.org/r/4934 : Bluetooth: A2DP: Added Disconnect API
- https://gerrit.zephyrproject.org/r/5109 : gpio: reduce Kconfigs and use consistent name for GPIOs
- https://gerrit.zephyrproject.org/r/5160 : net: yaip: events: Fix a mix up between code and command
- https://gerrit.zephyrproject.org/r/5134 : boards: Add support for Nordic Semiconductor nRF51 PCA10031
- https://gerrit.zephyrproject.org/r/5132 : arm: soc: Add support for Nordic Semiconductor nRF51 Series SoC
- https://gerrit.zephyrproject.org/r/5133 : drivers: update nRF5x drivers in preparation for nRF51x SoC
- https://gerrit.zephyrproject.org/r/5131 : arch: arm: cortex-m0 port
- https://gerrit.zephyrproject.org/r/5130 : Bluetooth: Controller: Alternate Enc procedure for nRF51x SoC
- https://gerrit.zephyrproject.org/r/5162 : Bluetooth: A2DP: Shell command for A2DP connection
- https://gerrit.zephyrproject.org/r/4883 : sanity: enable sanity multiple configuration
- https://gerrit.zephyrproject.org/r/27 : ci: test: checkpatch: warning space
- https://gerrit.zephyrproject.org/r/5010 : fs: Cleanup and reduce Kconfig flags used by file system
- https://gerrit.zephyrproject.org/r/4871 : util.h: Add DEFINED() macro for expresion-legal ifdef-checking

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5174 : net: Fix Kconfig indentation issue
- https://gerrit.zephyrproject.org/r/5168 : Bluetooth: Add BT_STORAGE_ADDRESSES key to storage API
- https://gerrit.zephyrproject.org/r/5165 : sanitycheck: Remove linker VMA/LMA offset checking
- https://gerrit.zephyrproject.org/r/5163 : Merge bluetooth branch into master
- https://gerrit.zephyrproject.org/r/5167 : Bluetooth: Improve storage API documentation
- https://gerrit.zephyrproject.org/r/5166 : Bluetooth: Use proper const type for bt_storage_clear()
- https://gerrit.zephyrproject.org/r/5170 : unified: Fix building of the unified kernel
- https://gerrit.zephyrproject.org/r/5169 : sanity: unified: implement sanity unified in all the builds
- https://gerrit.zephyrproject.org/r/5159 : Bluetooth: Start SMP over BR/EDR on pairing complete
- https://gerrit.zephyrproject.org/r/5158 : Bluetooth: SMP: Use separate pool for BR/EDR connections
- https://gerrit.zephyrproject.org/r/4511 : unified/doc: Kernel primer for unified kernel
- https://gerrit.zephyrproject.org/r/5157 : Bluetooth: SMP: Fix getting context for BR/EDR pairing
- https://gerrit.zephyrproject.org/r/5117 : eth: Rework LOG_ETHERNET_LEVEL config description.
- https://gerrit.zephyrproject.org/r/5156 : Bluetooth: L2CAP: Treat fixed channel as connected on incoming data
- https://gerrit.zephyrproject.org/r/5155 : Bluetooth: L2CAP: Connect optional fixed channel only if supported
- https://gerrit.zephyrproject.org/r/5128 : check_link_map: rewrite in python
- https://gerrit.zephyrproject.org/r/5011 : I2C: remove obsolete i2c_quark_se_ss driver
- https://gerrit.zephyrproject.org/r/5154 : Bluetooth: L2CAP: Move BR/EDR specific code to l2cap_br.c
- https://gerrit.zephyrproject.org/r/4846 : doc: FIFO API uses first 32 bits of data items
- https://gerrit.zephyrproject.org/r/5127 : unified: Fix build broblem caused by concurrent make processes in single dir
- https://gerrit.zephyrproject.org/r/5150 : drivers qmsi: Fix power management with reentrancy disabled
- https://gerrit.zephyrproject.org/r/4898 : drivers: shared irq: clean nested #if condition and align
- https://gerrit.zephyrproject.org/r/4979 : power_mgmt: Reduce complexity in handling of power hooks
- https://gerrit.zephyrproject.org/r/5135 : sanity: remove specific toolchain settings
- https://gerrit.zephyrproject.org/r/5054 : unified: Simplify k_msgq_purge()
- https://gerrit.zephyrproject.org/r/4868 : unified: Add tickless idle support for x86 and ARM
- https://gerrit.zephyrproject.org/r/4890 : unified: Enable tickless idle test
- https://gerrit.zephyrproject.org/r/5123 : unified: Rename k_thread_static_init structure
- https://gerrit.zephyrproject.org/r/5153 : Bluetooth: L2CAP: Build fixed channels mask on runtime
- https://gerrit.zephyrproject.org/r/5152 : Bluetooth: L2CAP: Initialize iterator inside for statement
- https://gerrit.zephyrproject.org/r/4983 : unified: Add k_work_pending
- https://gerrit.zephyrproject.org/r/4880 : nano_work: Add nano_work_pending
- https://gerrit.zephyrproject.org/r/4984 : unified: Don't assert if work is pending on submit
- https://gerrit.zephyrproject.org/r/4881 : nano_work: Don't assert if work is pending on submit
- https://gerrit.zephyrproject.org/r/5151 : Bluetooth: L2CAP: Rename br_channels to br_fixed_channels
- https://gerrit.zephyrproject.org/r/5136 : reviewers: use short numeric id instead of change ID
- https://gerrit.zephyrproject.org/r/4882 : util: adds downstream failure check script


Re: [RFC] Real-time interrupts

Benjamin Walsh <benjamin.walsh@...>
 

On Wed, Oct 05, 2016 at 03:24:55PM +0000, Cufi, Carles wrote:


-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: Tuesday, October 04, 2016 18:46
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Cc: Benjamin Walsh <benjamin.walsh(a)windriver.com>; Piotr Mienkowski
<piotr.mienkowski(a)schmid-telecom.ch>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: [RFC] Real-time interrupts

So I gather from the thread and IRC conversations that it makes sense
to create an IRQ_CONNECT_DIRECT macro along with (light) documentation
on the rights and responsibilities of ISRs connected using this
mechanism. That way we can use this for the BLE Controller that could
serve as a reference for future hard real-time interrupts.

If there's no objections I will create a Jira issue with this
information.

Should this replace the zero latency interrupt (ZLI) infrastructure
that is currently in the kernel? Or should it live side-by-side with
it?
They're related, but not exactly the same.

ZLIs cannot call kernel functionalities, because lots of kernel
operations rely on locking interrupts, and ZLIs ignore interrupt
locking; "real-time" interrupts would still be able to call kernel
functionalities, if the invoke _IntExit() when they're done. Enabling
ZLI just punches a hole in the range of interrupt priorities that are
locked when locking interrupts.

Both ZLIs and RT interrupts have to be installed directly in the vector
table.

We also have to be careful about how we're handling tickless idle and
power management for RT interrupts.
Thanks for the info Ben.

I've created a Jira issue for this:
https://jira.zephyrproject.org/browse/ZEP-1038
Yup, saw that, thanks. I'll just turn it into a user-story rather than a
task.


Re: [RFC] Real-time interrupts

Carles Cufi
 

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: Tuesday, October 04, 2016 18:46
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Cc: Benjamin Walsh <benjamin.walsh(a)windriver.com>; Piotr Mienkowski
<piotr.mienkowski(a)schmid-telecom.ch>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: [RFC] Real-time interrupts

So I gather from the thread and IRC conversations that it makes sense
to create an IRQ_CONNECT_DIRECT macro along with (light) documentation
on the rights and responsibilities of ISRs connected using this
mechanism. That way we can use this for the BLE Controller that could
serve as a reference for future hard real-time interrupts.

If there's no objections I will create a Jira issue with this
information.

Should this replace the zero latency interrupt (ZLI) infrastructure
that is currently in the kernel? Or should it live side-by-side with
it?
They're related, but not exactly the same.

ZLIs cannot call kernel functionalities, because lots of kernel
operations rely on locking interrupts, and ZLIs ignore interrupt
locking; "real-time" interrupts would still be able to call kernel
functionalities, if the invoke _IntExit() when they're done. Enabling
ZLI just punches a hole in the range of interrupt priorities that are
locked when locking interrupts.

Both ZLIs and RT interrupts have to be installed directly in the vector
table.

We also have to be careful about how we're handling tickless idle and
power management for RT interrupts.
Thanks for the info Ben.

I've created a Jira issue for this:
https://jira.zephyrproject.org/browse/ZEP-1038

Carles


Re: Gerrit' SSH's fingerprints are out of date

Fabien Parent <fparent@...>
 

On Wed, Oct 5, 2016 at 5:06 PM, Andy Ross <andrew.j.ross(a)intel.com> wrote:
Fabien Parent wrote (on Wednesday, October 05, 2016 7:56AM):
[...] But when I tried to communicate with the gerrit server my
connection got rejected because of a mismatch of the RSA
fingerprint. [...] I will wait for the fingerprints to be updated
before pushing any changes to your gerrit.
Those fingerprints are stored on your local machine, there's no need
for a server admin to address this. This is what I have if you want
to verify, it's been consistent for the past few months at least
(frankly I don't know if it's ever been changed). If you want to fix
the problem, just remove that line in known_hosts and reconnect:

$ fgrep gerrit.zephyrproject.org .ssh/known_hosts
[gerrit.zephyrproject.org]:29418 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDLhAICjKMqwNREHPZvs95Hlk8HfGt2VX3i5qUBJCyQ6unqmnlxy7xf1TDWCw6Tnq4jJH3/9SplNYONy5uwvLDtUoLrSG4kD6vvYUjgMB6pa/ECtefMnPkhCv09XOdfzWfku3O9GQRO8cpzoZZSV1NqIR2VVde1Xs2dbBXAwkLW8F0VFNOYs1ihApEAQWYf+hi3j+FcZP/9VnI7kg1XVJttfBJIlm05BjAkyQ+cSllgVAEi4iW1Q2KZ2iDwhdzTlwa+FpLnezFJtYR+v9449Fz2tMgBDl30p3A1bPvBwndxMsiddxjVRGuj2oTzAwkSYLS2hXT5pZOl7DOrSt3sTCKD

Andy
While I was removing the fingerprint, I noticed that I added the same
fingerprint twice instead of adding each one, and of course that was
not the one that was used. I feel dumb now. I added the second
fingerprint and it works.

Sorry for the noise.


Re: Gerrit' SSH's fingerprints are out of date

Andy Ross
 

Fabien Parent wrote (on Wednesday, October 05, 2016 7:56AM):
[...] But when I tried to communicate with the gerrit server my
connection got rejected because of a mismatch of the RSA
fingerprint. [...] I will wait for the fingerprints to be updated
before pushing any changes to your gerrit.
Those fingerprints are stored on your local machine, there's no need
for a server admin to address this. This is what I have if you want
to verify, it's been consistent for the past few months at least
(frankly I don't know if it's ever been changed). If you want to fix
the problem, just remove that line in known_hosts and reconnect:

$ fgrep gerrit.zephyrproject.org .ssh/known_hosts
[gerrit.zephyrproject.org]:29418 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDLhAICjKMqwNREHPZvs95Hlk8HfGt2VX3i5qUBJCyQ6unqmnlxy7xf1TDWCw6Tnq4jJH3/9SplNYONy5uwvLDtUoLrSG4kD6vvYUjgMB6pa/ECtefMnPkhCv09XOdfzWfku3O9GQRO8cpzoZZSV1NqIR2VVde1Xs2dbBXAwkLW8F0VFNOYs1ihApEAQWYf+hi3j+FcZP/9VnI7kg1XVJttfBJIlm05BjAkyQ+cSllgVAEi4iW1Q2KZ2iDwhdzTlwa+FpLnezFJtYR+v9449Fz2tMgBDl30p3A1bPvBwndxMsiddxjVRGuj2oTzAwkSYLS2hXT5pZOl7DOrSt3sTCKD

Andy


Gerrit' SSH's fingerprints are out of date

Fabien Parent <fparent@...>
 

Hello,

My companies has been working on adding the support to Zephyr of
another STM32 SoC, and I have been asked to try to upstream that work.
So today I set up my gerrit account, added the 2 RSA fingerprints
provided by the gerrit UI to my known_hosts file. But when I tried to
communicate with the gerrit server my connection got rejected because
of a mismatch of the RSA fingerprint.

My guess is that nobody is trying to eavesdrop me and that the
fingerprint is obsolete, so I think it would be useful to update it. I
will wait for the fingerprints to be updated before pushing any
changes to your gerrit.

Thank you very much,
Fabien

6381 - 6400 of 8046