Date   

[PATCH 6/8] gpio: Remove suspend/resume from GPIO API

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Device suspend/resume API is now implemented in top level device API.

Change-Id: I2386765813aee2a94e54cb2914ee9ec3644b90c7
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/gpio.h | 27 ---------------------------
1 file changed, 27 deletions(-)

diff --git a/include/gpio.h b/include/gpio.h
index b79c393..3a5e213 100644
--- a/include/gpio.h
+++ b/include/gpio.h
@@ -160,8 +160,6 @@ struct gpio_driver_api {
gpio_set_callback_t set_callback;
gpio_enable_callback_t enable_callback;
gpio_disable_callback_t disable_callback;
- gpio_suspend_port_t suspend;
- gpio_resume_port_t resume;
};
/**
* @endcond
@@ -325,31 +323,6 @@ static inline int gpio_port_disable_callback(struct device *port)
return api->disable_callback(port, GPIO_ACCESS_BY_PORT, 0);
}

-/**
- * @brief Save the state of the device and make it go to the
- * low power state.
- * @param port Pointer to the device structure for the driver instance.
- */
-static inline int gpio_suspend(struct device *port)
-{
- struct gpio_driver_api *api;
-
- api = (struct gpio_driver_api *) port->driver_api;
- return api->suspend(port);
-}
-
-/**
- * @brief Restore the state stored during suspend and resume operation.
- * @param port Pointer to the device structure for the driver instance.
- */
-static inline int gpio_resume(struct device *port)
-{
- struct gpio_driver_api *api;
-
- api = (struct gpio_driver_api *) port->driver_api;
- return api->resume(port);
-}
-
#ifdef __cplusplus
}
#endif
--
2.4.3


[PATCH 5/7] gpio: Remove suspend/resume from GPIO API

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Device suspend/resume API is now implemented in top level device API.

Change-Id: I2386765813aee2a94e54cb2914ee9ec3644b90c7
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/gpio.h | 27 ---------------------------
1 file changed, 27 deletions(-)

diff --git a/include/gpio.h b/include/gpio.h
index b79c393..3a5e213 100644
--- a/include/gpio.h
+++ b/include/gpio.h
@@ -160,8 +160,6 @@ struct gpio_driver_api {
gpio_set_callback_t set_callback;
gpio_enable_callback_t enable_callback;
gpio_disable_callback_t disable_callback;
- gpio_suspend_port_t suspend;
- gpio_resume_port_t resume;
};
/**
* @endcond
@@ -325,31 +323,6 @@ static inline int gpio_port_disable_callback(struct device *port)
return api->disable_callback(port, GPIO_ACCESS_BY_PORT, 0);
}

-/**
- * @brief Save the state of the device and make it go to the
- * low power state.
- * @param port Pointer to the device structure for the driver instance.
- */
-static inline int gpio_suspend(struct device *port)
-{
- struct gpio_driver_api *api;
-
- api = (struct gpio_driver_api *) port->driver_api;
- return api->suspend(port);
-}
-
-/**
- * @brief Restore the state stored during suspend and resume operation.
- * @param port Pointer to the device structure for the driver instance.
- */
-static inline int gpio_resume(struct device *port)
-{
- struct gpio_driver_api *api;
-
- api = (struct gpio_driver_api *) port->driver_api;
- return api->resume(port);
-}
-
#ifdef __cplusplus
}
#endif
--
2.4.3


[PATCH 5/8] device: pm: Add API for power management entity to register pm callbacks

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Provide a mechanism for the power management infrastructure to be
notified of power management events in the driver.

Change-Id: If78fe3610679ba82c52c1ef056781f8afd0be352
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 18 ++++++++++++++++++
include/pm.h | 25 +++++++++++++++++++++++++
2 files changed, 43 insertions(+)
create mode 100644 include/pm.h

diff --git a/include/device.h b/include/device.h
index 793b68f..95fbcb4 100644
--- a/include/device.h
+++ b/include/device.h
@@ -33,6 +33,8 @@
extern "C" {
#endif

+#include <pm.h>
+
/**
* @def DEVICE_INIT
*
@@ -230,6 +232,8 @@ struct device;
struct device_ops {
int (*suspend)(struct device *device);
int (*resume)(struct device *device);
+ void (*register_pm_ops)(struct device *device,
+ struct pm_ops *pm_ops, void *context);
};

/**
@@ -278,6 +282,20 @@ static inline int device_resume(struct device *device)
return device->config->dev_ops->resume(device);
}

+static inline int _null_device_register_pm_ops(struct device *device,
+ struct pm_ops *pm_ops,
+ void *context)
+{
+ return 0;
+};
+
+static inline void device_register_pm_ops(struct device *device,
+ struct pm_ops *pm_ops,
+ void *context)
+{
+ device->config->dev_ops->register_pm_ops(device, pm_ops, context);
+}
+
/**
* Synchronous calls API
*/
diff --git a/include/pm.h b/include/pm.h
new file mode 100644
index 0000000..a63e693
--- /dev/null
+++ b/include/pm.h
@@ -0,0 +1,25 @@
+
+/*
+ * Copyright (c) 2015 Intel Corporation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef _PM_H_
+#define _PM_H_
+
+struct pm_ops {
+ void (*suspend)(void* context);
+ void (*resume)(void* context);
+};
+#endif /* _PM_H_ */
--
2.4.3


[PATCH 4/7] device: pm: Add API for power management entity to register pm callbacks

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Provide a mechanism for the power management infrastructure to be
notified of power management events in the driver.

Change-Id: If78fe3610679ba82c52c1ef056781f8afd0be352
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 18 ++++++++++++++++++
include/pm.h | 25 +++++++++++++++++++++++++
2 files changed, 43 insertions(+)
create mode 100644 include/pm.h

diff --git a/include/device.h b/include/device.h
index 793b68f..95fbcb4 100644
--- a/include/device.h
+++ b/include/device.h
@@ -33,6 +33,8 @@
extern "C" {
#endif

+#include <pm.h>
+
/**
* @def DEVICE_INIT
*
@@ -230,6 +232,8 @@ struct device;
struct device_ops {
int (*suspend)(struct device *device);
int (*resume)(struct device *device);
+ void (*register_pm_ops)(struct device *device,
+ struct pm_ops *pm_ops, void *context);
};

/**
@@ -278,6 +282,20 @@ static inline int device_resume(struct device *device)
return device->config->dev_ops->resume(device);
}

+static inline int _null_device_register_pm_ops(struct device *device,
+ struct pm_ops *pm_ops,
+ void *context)
+{
+ return 0;
+};
+
+static inline void device_register_pm_ops(struct device *device,
+ struct pm_ops *pm_ops,
+ void *context)
+{
+ device->config->dev_ops->register_pm_ops(device, pm_ops, context);
+}
+
/**
* Synchronous calls API
*/
diff --git a/include/pm.h b/include/pm.h
new file mode 100644
index 0000000..a63e693
--- /dev/null
+++ b/include/pm.h
@@ -0,0 +1,25 @@
+
+/*
+ * Copyright (c) 2015 Intel Corporation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef _PM_H_
+#define _PM_H_
+
+struct pm_ops {
+ void (*suspend)(void* context);
+ void (*resume)(void* context);
+};
+#endif /* _PM_H_ */
--
2.4.3


[PATCH 4/8] device: Add API to suspend/resume all devices in the system.

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Change-Id: Iea0f97998bec4e2b0443a8fcc712dad71d42ae54
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 2 ++
kernel/nanokernel/device.c | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+)

diff --git a/include/device.h b/include/device.h
index 40adbe8..793b68f 100644
--- a/include/device.h
+++ b/include/device.h
@@ -260,6 +260,8 @@ struct device {

void _sys_device_do_config_level(int level);
struct device* device_get_binding(char *name);
+void device_suspend_all(void);
+void device_resume_all(void);

static inline int _null_suspend_resume(struct device *device)
{
diff --git a/kernel/nanokernel/device.c b/kernel/nanokernel/device.c
index f86f95f..e862ef8 100644
--- a/kernel/nanokernel/device.c
+++ b/kernel/nanokernel/device.c
@@ -42,6 +42,46 @@ void _sys_device_do_config_level(int level)
}

/**
+ * @brief Execute all the device suspend proceedures
+ *
+ * @details Invokes the suspend routine for each device object
+ * created by the SYS_DEFINE_DEVICE_PM().
+ * The linker script places the device objects in memory in the order
+ * required to maintain device dependencies.
+ *
+ */
+void device_suspend_all(void)
+{
+ struct device *info;
+
+ for (info = __device_init_end -1 ;
+ info > __device_init_start ; info--) {
+ struct device_config *device = info->config;
+ device->dev_ops->suspend(info);
+ }
+}
+
+/**
+ * @brief Execute all the device resume proceedures
+ *
+ * @details Invokes the resume routine for each device object
+ * created by the SYS_DEFINE_DEVICE_PM().
+ * The linker script places the device objects in memory in the order
+ * required to maintain device dependencies.
+ *
+ */
+void device_resume_all(void)
+{
+ struct device *info;
+
+ for (info = __device_init_start;
+ info < __device_init_end ; info++) {
+ struct device_config *device = info->config;
+ device->dev_ops->resume(info);
+ }
+}
+
+/**
* @brief Retrieve the device structure for a driver by name
*
* @details Device objects are created via the DEVICE_INIT() macro and
--
2.4.3


[PATCH 3/8] device: Add generic device_{suspend, resume}() API

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Provide an API to call the device suspend/resume functions.

Change-Id: I352481897a4bf431fc9eb78540fc81f5e552c4be
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/include/device.h b/include/device.h
index 5dbb52f..40adbe8 100644
--- a/include/device.h
+++ b/include/device.h
@@ -266,6 +266,16 @@ static inline int _null_suspend_resume(struct device *device)
return 0;
};

+static inline int device_suspend(struct device *device)
+{
+ return device->config->dev_ops->suspend(device);
+}
+
+static inline int device_resume(struct device *device)
+{
+ return device->config->dev_ops->resume(device);
+}
+
/**
* Synchronous calls API
*/
--
2.4.3


[PATCH 3/7] device: Add API to suspend/resume all devices in the system.

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Change-Id: Iea0f97998bec4e2b0443a8fcc712dad71d42ae54
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 2 ++
kernel/nanokernel/device.c | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+)

diff --git a/include/device.h b/include/device.h
index 40adbe8..793b68f 100644
--- a/include/device.h
+++ b/include/device.h
@@ -260,6 +260,8 @@ struct device {

void _sys_device_do_config_level(int level);
struct device* device_get_binding(char *name);
+void device_suspend_all(void);
+void device_resume_all(void);

static inline int _null_suspend_resume(struct device *device)
{
diff --git a/kernel/nanokernel/device.c b/kernel/nanokernel/device.c
index f86f95f..e862ef8 100644
--- a/kernel/nanokernel/device.c
+++ b/kernel/nanokernel/device.c
@@ -42,6 +42,46 @@ void _sys_device_do_config_level(int level)
}

/**
+ * @brief Execute all the device suspend proceedures
+ *
+ * @details Invokes the suspend routine for each device object
+ * created by the SYS_DEFINE_DEVICE_PM().
+ * The linker script places the device objects in memory in the order
+ * required to maintain device dependencies.
+ *
+ */
+void device_suspend_all(void)
+{
+ struct device *info;
+
+ for (info = __device_init_end -1 ;
+ info > __device_init_start ; info--) {
+ struct device_config *device = info->config;
+ device->dev_ops->suspend(info);
+ }
+}
+
+/**
+ * @brief Execute all the device resume proceedures
+ *
+ * @details Invokes the resume routine for each device object
+ * created by the SYS_DEFINE_DEVICE_PM().
+ * The linker script places the device objects in memory in the order
+ * required to maintain device dependencies.
+ *
+ */
+void device_resume_all(void)
+{
+ struct device *info;
+
+ for (info = __device_init_start;
+ info < __device_init_end ; info++) {
+ struct device_config *device = info->config;
+ device->dev_ops->resume(info);
+ }
+}
+
+/**
* @brief Retrieve the device structure for a driver by name
*
* @details Device objects are created via the DEVICE_INIT() macro and
--
2.4.3


[PATCH 2/7] device: Add generic device_{suspend, resume}() API

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Provide an API to call the device suspend/resume functions.

Change-Id: I352481897a4bf431fc9eb78540fc81f5e552c4be
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/include/device.h b/include/device.h
index 5dbb52f..40adbe8 100644
--- a/include/device.h
+++ b/include/device.h
@@ -266,6 +266,16 @@ static inline int _null_suspend_resume(struct device *device)
return 0;
};

+static inline int device_suspend(struct device *device)
+{
+ return device->config->dev_ops->suspend(device);
+}
+
+static inline int device_resume(struct device *device)
+{
+ return device->config->dev_ops->resume(device);
+}
+
/**
* Synchronous calls API
*/
--
2.4.3


[PATCH 2/8] device: Add _null_suspend_resume() function

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Some devices may have no work to do in suspend/resume, but every
device is required to provided a suspend/resume function to the power
management subsystem. Provide generic noop suspend/resume functions
to be reused by devices saving the code space for every device
defining their own noop functions.

Change-Id: Ia1c2edd97fc9cdaff36967f2e4901fadbaca65bf
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/include/device.h b/include/device.h
index 64b1e6f..5dbb52f 100644
--- a/include/device.h
+++ b/include/device.h
@@ -261,6 +261,11 @@ struct device {
void _sys_device_do_config_level(int level);
struct device* device_get_binding(char *name);

+static inline int _null_suspend_resume(struct device *device)
+{
+ return 0;
+};
+
/**
* Synchronous calls API
*/
--
2.4.3


[PATCH 1/8] device: Add suspend/resume api functions to device structure

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Suspend and resume are generic functions that each device should
support. Move the suspend/resume API functions to the top level
device structure. This change allows for the application to call
suspend/resume without needing to know device type.

Change-Id: I2fa7b13f75faeb83106ced83cd07ddbae4c915d6
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 74 insertions(+)

diff --git a/include/device.h b/include/device.h
index e2e657d..64b1e6f 100644
--- a/include/device.h
+++ b/include/device.h
@@ -147,6 +147,70 @@ extern "C" {
*/
#define DEVICE_DECLARE(name) extern struct device DEVICE_NAME_GET(name)

+/**
+ * @def DEVICE_INIT_PM
+ *
+ * @brief create device object and set it up for boot time initialization
+ *
+ * @details This macro defines a device object that is automatically
+ * configured by the kernel during system initialization.
+ *
+ * @param dev_name Device name.
+ *
+ * @param drv_name The name this instance of the driver exposes to
+ * the system.
+ *
+ * @param init_fn Address to the init function of the driver.
+ *
+ * @param device_fn Address of device_ops structure for device.
+ *
+ * @param data Pointer to the device's configuration data.
+ *
+ * @param cfg_info The address to the structure containing the
+ * configuration information for this instance of the driver.
+ *
+ * @param level The initialization level at which configuration occurs.
+ * Must be one of the following symbols, which are listed in the order
+ * they are performed by the kernel:
+ *
+ * PRIMARY: Used for devices that have no dependencies, such as those
+ * that rely solely on hardware present in the processor/SOC. These devices
+ * cannot use any kernel services during configuration, since they are not
+ * yet available.
+ *
+ * SECONDARY: Used for devices that rely on the initialization of devices
+ * initialized as part of the PRIMARY level. These devices cannot use any
+ * kernel services during configuration, since they are not yet available.
+ *
+ * NANOKERNEL: Used for devices that require nanokernel services during
+ * configuration.
+ *
+ * MICROKERNEL: Used for devices that require microkernel services during
+ * configuration.
+ *
+ * APPLICATION: Used for application components (i.e. non-kernel components)
+ * that need automatic configuration. These devices can use all services
+ * provided by the kernel during configuration.
+ *
+ * @param prio The initialization priority of the device, relative to
+ * other devices of the same initialization level. Specified as an integer
+ * value in the range 0 to 99; lower values indicate earlier initialization.
+ * Must be a decimal integer literal without leading zeroes or sign (e.g. 32),
+ * or an equivalent symbolic name (e.g. #define MY_INIT_PRIO 32); symbolic
+ * expressions are *not* permitted
+ * (e.g. CONFIG_KERNEL_INIT_PRIORITY_DEFAULT + 5).
+ */
+
+#define DECLARE_INIT_PM(cfg_name, drv_name, init_fn, \
+ device_fn, config)\
+ static struct device_config config_##cfg_name __used \
+ __attribute__((__section__(".devconfig.init"))) = { \
+ .name = drv_name, .init = (init_fn), \
+ .dev_ops = device_fn, \
+ .config_info = (config) \
+ }
+
+
/* Common Error Codes devices can provide */
#define DEV_OK 0 /* No error */
#define DEV_FAIL 1 /* General operation failure */
@@ -160,6 +224,15 @@ extern "C" {
struct device;

/**
+ * @brief Specify the operations common across all devices
+ * @param init init function for the driver
+ */
+struct device_ops {
+ int (*suspend)(struct device *device);
+ int (*resume)(struct device *device);
+};
+
+/**
* @brief Static device information (In ROM) Per driver instance
* @param name name of the device
* @param init init function for the driver
@@ -168,6 +241,7 @@ struct device;
struct device_config {
char *name;
int (*init)(struct device *device);
+ struct device_ops *dev_ops;
void *config_info;
};

--
2.4.3


[PATCH 1/7] device: Add _null_suspend_resume() function

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Some devices may have no work to do in suspend/resume, but every
device is required to provided a suspend/resume function to the power
management subsystem. Provide generic noop suspend/resume functions
to be reused by devices saving the code space for every device
defining their own noop functions.

Change-Id: Ia1c2edd97fc9cdaff36967f2e4901fadbaca65bf
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/include/device.h b/include/device.h
index 64b1e6f..5dbb52f 100644
--- a/include/device.h
+++ b/include/device.h
@@ -261,6 +261,11 @@ struct device {
void _sys_device_do_config_level(int level);
struct device* device_get_binding(char *name);

+static inline int _null_suspend_resume(struct device *device)
+{
+ return 0;
+};
+
/**
* Synchronous calls API
*/
--
2.4.3


[PATCH 0/8] Adding generic suspend/resume infrasturcture.

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Since this change set was loosely based on my RFC on the subject prior
to release it is worth bringing the orginal design into this thread.

Given that most/all platforms we are targeting will care deeply about
power consumption this patch set changes the device model to *require*
that every driver do something about suspend/resume even it is just
providing a null implementation if there is nothing the device needs
to do during a suspend/resume cycle.

This patch does the following things:
Adds suspend/resume to *all* devices.

Provides a null suspend/resume implementation that can be used by
*all* drivers.

Provides an interface for the power management infrastrcuture (PMI) to
call suspend/resume on the device without needing to know the type
of the device.

Provides an interface where the PMI can register callbacks with the
driver to be called when suspend has completed and resume has
started. These call backs allow the PMI to do any processing
required to complete the suspend/resume of the device. e.g. clock
control, power to IP block. This is needed since there may be
multiple devices attached to a single clock or power island which
can only be disabled once all attached devices are suspended and
must be turned on prior to the first device resuming.

This keeps *all* the information about a device in one place. Forces
all drivers to support the suspend/resume interface.

This will require that all the current drivers be updated to support
the new interface. Now is the right time to do this before we get a
*bunch* more drivers added to the tree.

Patch 1 adds a PM enabled version of DEVICE_INIT() which is only there
to keep things building while the drivers are being updated. Once all
the drivers have been updated we can remove the extra macro with a
single tree wide change.

The API to suspend/resume all devices in the system was meant to show
how the PMI might want to suspend all devices and is not complete
since there is no error handling. After thinking about it more it is
not clear to me that we should provide this convienence API.

The changes to the GPIO interface and driver are meant to illustrate
the changes that will need to be applied to all the drivers in the
system.

Dirk Brandewie (8):
device: Add suspend/resume api functions to device structure
device: Add _null_suspend_resume() function
device: Add generic device_{suspend, resume}() API
device: Add API to suspend/resume all devices in the system.
device: pm: Add API for power management entity to register pm
callbacks
gpio: Remove suspend/resume from GPIO API
gpio: gpio_dw: Use generic suspend suspend/resume API
gpio: gpio_dw: Add suport for device_register_pm_ops()

drivers/gpio/gpio_dw.c | 48 ++++++++++++++++----
drivers/gpio/gpio_dw.h | 2 +
include/device.h | 109 +++++++++++++++++++++++++++++++++++++++++++++
include/gpio.h | 27 -----------
include/pm.h | 25 +++++++++++
kernel/nanokernel/device.c | 40 +++++++++++++++++
6 files changed, 216 insertions(+), 35 deletions(-)
create mode 100644 include/pm.h

--
2.4.3


Re: RFC: Counter driver API

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

There are 2 aon counters:

Aon counter => monotinic counter without interrupt
Aon periodic timer => periodic timer with interrupt support

Regards,
Alex.

-----Original Message-----
From: Dirk Brandewie [mailto:dirk.j.brandewie(a)intel.com]
Sent: Monday, February 29, 2016 16:09
To: Tseng, Kuo-Lang <kuo-lang.tseng(a)intel.com>;
devel(a)lists.zephyrproject.org
Cc: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>
Subject: [devel] Re: RFC: Counter driver API



On 02/26/2016 12:29 PM, Tseng, Kuo-Lang wrote:
Hi,

As per suggestion from Gerrit comment, moving the discussion to mailing
list.

Background
--------------

On Quark (SE and D2000), there are Always On Counter (free running) and
Always ON Periodic Timer devices. A counter|timer driver is to be added for
supporting these devices. At same time, the goal is to create an API that is
generic enough for not just these two specific devices.

Proposal:
-----------

Generic counter driver API:
-------------------------------
We will have 3 routines - start, stop, and read, which takes in the device
pointer - which identifies the timer. The driver header, counter.h, is under
/include folder:

/**
* @brief Set up counter configuration and start it.
* @param dev Pointer to the device structure for the driver instance.
* @param config Pointer to counter configuration structure
*
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
*/
int counter_start(struct device *dev, counter_input *config);

/**
* @brief Stop the counter.
* @param dev Pointer to the device structure for the driver instance.
*
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
*/
int counter_stop(struct device *dev);

/**
* @brief Read current counter value
* @param dev Pointer to the device structure for the driver instance.
*
* @return 32-bit value
*/
uint32_t counter_read(struct device *dev)

The counter_input structure can be something like below:

/**
* @brief Counter configuration.
*
* Acceptable setting in the configuration structure is hardware-
specific.
*
* initial_value - Initial value to load to the counter or timer.
* callback - Callback function when timer expires.
*/
struct counter_input {
uint32_t initial_value;
end_count/expiration_count something like like that so the reader knows how
the value is used.

void (*callback)(void);
};

Note - Using structure, tomorrow we can add more fields for a counter with
more features.
For the Free Running counter in Quark, these fields would be null as it
does not support interrupt or callback notification.
Confused by this note. The always on counter does have an interrupt it the
only way for the device to signal counter expiration.

The hardware-specific driver implementation:
-----------------------------------

This can be implemented in /drivers directory. For example, for Quark SE
and D2000, we can have below file which implements the API functionality
using the AON Counter and AON Periodic Timer:

drivers/quark_aon_counter.c

Comment, feedback welcome.
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

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


Re: RFC: Counter driver API

Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/26/2016 12:29 PM, Tseng, Kuo-Lang wrote:
Hi,

As per suggestion from Gerrit comment, moving the discussion to mailing list.

Background
--------------

On Quark (SE and D2000), there are Always On Counter (free running) and Always ON Periodic Timer devices. A counter|timer driver is to be added for supporting these devices. At same time, the goal is to create an API that is generic enough for not just these two specific devices.

Proposal:
-----------

Generic counter driver API:
-------------------------------
We will have 3 routines - start, stop, and read, which takes in the device pointer - which identifies the timer. The driver header, counter.h, is under /include folder:

/**
* @brief Set up counter configuration and start it.
* @param dev Pointer to the device structure for the driver instance.
* @param config Pointer to counter configuration structure
*
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
*/
int counter_start(struct device *dev, counter_input *config);

/**
* @brief Stop the counter.
* @param dev Pointer to the device structure for the driver instance.
*
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
*/
int counter_stop(struct device *dev);

/**
* @brief Read current counter value
* @param dev Pointer to the device structure for the driver instance.
*
* @return 32-bit value
*/
uint32_t counter_read(struct device *dev)

The counter_input structure can be something like below:

/**
* @brief Counter configuration.
*
* Acceptable setting in the configuration structure is hardware-specific.
*
* initial_value - Initial value to load to the counter or timer.
* callback - Callback function when timer expires.
*/
struct counter_input {
uint32_t initial_value;
end_count/expiration_count something like like that so the reader knows
how the value is used.

void (*callback)(void);
};

Note - Using structure, tomorrow we can add more fields for a counter with more features.
For the Free Running counter in Quark, these fields would be null as it does not support interrupt or callback notification.
Confused by this note. The always on counter does have an interrupt
it the only way for the device to signal counter expiration.

The hardware-specific driver implementation:
-----------------------------------

This can be implemented in /drivers directory. For example, for Quark SE and D2000, we can have below file which implements the API functionality using the AON Counter and AON Periodic Timer:

drivers/quark_aon_counter.c

Comment, feedback welcome.


Re: RFC - arm-gcc-embedded Toolchain Support

Nashif, Anas
 

Hugo,

Looks good to me. You can also do that by specifying CROSS_COMPILE at the command line, for example:

CROSS_COMPILE=arm-none-eabi- make BOARD=qemu_cortex_m3

will build using the installed ARM toolchain on my host. You do not need to specify the VARIANT.


Thanks,
Anas

From: Hugo Vincent <hugo.vincent(a)gmail.com<mailto:hugo.vincent(a)gmail.com>>
Date: To: "devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>" <devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>>
Subject: [devel] RFC - arm-gcc-embedded Toolchain Support

Hi,

One of the complications of setting up a Zephyr development environment, especially on OS X, is having to get and build CrossTool-NG. ARM maintains an official distro and build of gcc and family for Cortex-M and Cortex-R at https://launchpad.net/gcc-arm-embedded, which provides pre-built binaries for Windows, Linux and Mac OS X.

I created a simple, minimal Makefile.toolchain.gcc-arm-embedded that adds support for this toolchain to Zephyr, see attached patch. If there is interest in accepting this, I can add qemu and OpenOCD to this, as well as update the documentation, as well as generalising/parameterising the paths etc. Please advise how to proceed.

I tested on the frdm_k64f board, with versions 4.9-2015-q2-update and 5.0-2015-q4-major of the toolchain, and with several of the example applications, and they all functioned correctly.

(There is also another hunk in the patch that adds .DS_Store to gitignore -- it's a metadata file generated by the OS X Finder, and can be safely ignored).

Regards,
Hugo

(Disclaimer: I work at ARM, but this is a personal contribution).


RFC - arm-gcc-embedded Toolchain Support

Hugo Vincent
 

Hi,

One of the complications of setting up a Zephyr development environment,
especially on OS X, is having to get and build CrossTool-NG. ARM maintains
an official distro and build of gcc and family for Cortex-M and Cortex-R at
https://launchpad.net/gcc-arm-embedded, which provides pre-built binaries
for Windows, Linux and Mac OS X.

I created a simple, minimal Makefile.toolchain.gcc-arm-embedded that adds
support for this toolchain to Zephyr, see attached patch. If there is
interest in accepting this, I can add qemu and OpenOCD to this, as well as
update the documentation, as well as generalising/parameterising the paths
etc. Please advise how to proceed.

I tested on the frdm_k64f board, with versions 4.9-2015-q2-update and
5.0-2015-q4-major of the toolchain, and with several of the example
applications, and they all functioned correctly.

(There is also another hunk in the patch that adds .DS_Store to gitignore
-- it's a metadata file generated by the OS X Finder, and can be safely
ignored).

Regards,
Hugo

(Disclaimer: I work at ARM, but this is a personal contribution).


Re: Building project

Nashif, Anas
 

You have a typo in your makefile? mico instead of micro?

Anas

From: Corey Williamson <corey.bailey.williamson(a)gmail.com<mailto:corey.bailey.williamson(a)gmail.com>>
Date: To: "devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>" <devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>>
Subject: [devel] Building project

Hi,

I'm currently trying to build the hello world example in a directory outside the zephyr SDK and I keep getting this make error:

corey(a)corey-H97M-D3H:~/ZephyrWorkspace/eclipse_workspace/hello_world$ make
Using /home/corey/ZephyrWorkspace/zephyr-project/boards/frdm_k64f/frdm_k64f_defconfig as base
Merging /home/corey/ZephyrWorkspace/zephyr-project/kernel/configs/mico.config
The merge file '/home/corey/ZephyrWorkspace/zephyr-project/kernel/configs/mico.config' does not exist. Exit.
make: *** [/home/corey/ZephyrWorkspace/eclipse_workspace/hello_world/outdir/.config] Error 1

I thought I might be environment variables but I echoed ZEPHYR_BASE and it was correct.

Any help is much appreciated,

Thanks!

Corey


RFC [3/3] - SoC, CPU LPS, Tickless idle and Device power management

Thomas, Ramesh
 

Areas to be implemented next:
1. ARC deep sleep support:
- Currently ARC in quark_se would be reset upon deep sleep initiated
from x86 core. It needs something like _sys_soc_resume() called at boot
time so it can restore states and resume at the point it suspended.

Suspend would be invoked from the x86 side so there is no need for a
suspend function.

2. Nanokernel tickless idle PM support:
- Currently tickless idle PM hooks are called only in microkernel idle
task. The same hook functions should also be called from nanokernel
tickless idle. Microkernel and Nanokernel implementations would
be consolidated. This consolidation would also make names of functions
uniform.


3. The naming of CONFIG flags and functions:
- The CONFIG flag names would be made consistent with the new power
management implementation. Also the dependencies between the flags
would be improved and unnecessary fags removed.

Feedbacks/Suggestions:
1. Provide arch specific helper functions used in the PM service app to
do state transitions and save/restore CPU thread contexts.
- Zephyr has arch specific code in arch folders. The suggestion is to
add functions in these locations and abstract them to the PM service app.


RFC [2/3] - SoC, CPU LPS, Tickless idle and Device power management

Thomas, Ramesh
 

***These are implemented and under review***
https://gerrit.zephyrproject.org/r/#/c/532/
https://gerrit.zephyrproject.org/r/#/c/528/
https://gerrit.zephyrproject.org/r/#/c/525/

Device driver power management hook infrastructure
------------------------------------------------------
When the _sys_soc_suspend() and _sys_soc_resume() hook functions are
called, the PM service app may want to do some device specific
operations. Zephyr kernel provides this infrastructure to enable device
drivers to define suspend and resume hook functions that can be called
by the PM service app.

Following are the goals for providing this infrastructure:
1. A framework for drivers to implement generic suspend/resume hook
functions.
2. Provide means for PM app service to call the suspend and resume
functions of all devices in the system. This is necessary especially to
do suspend and resume operations on system devices like the APIC device
which do not export device binding interface.
3. Since not all devices need to implement suspend and resume hook
functions, provide a no-op function by default for such devices. By
default all devices would be setup with the no-op function for their
hooks. The device drivers who need specific handling would assign the
addresses of the functions they implement to these hooks during
initialization.

Non-goals:
The implementation of the hook functions by the device drivers is up to
each driver, the integrator and the system power management policies.

All device power management infrastructure implementations is enclosed
inside CONFIG_DEVICE_POWER flag.

The hook functions for the PM service app:
a) int device_suspend(struct device *port)
param port:
Device structure of the driver instance

return:
DEV_OK for success, error code otherwise

Details - calls the suspend hook of the device associated with the
device structure parameter.

b) int device_resume(struct device *port)
param port:
Device structure of the driver instance

return:
DEV_OK for success, error code otherwise

Details - calls the resume hook of the device associated with the device
structure parameter.

c) void device_suspend_all(bool system_devices)
param system_devices
Boolean true for only the system devices; else all devices

Details:
Kernel holds a list of all devices in the system. This function will
iterate through that list and call the suspend hook function of each
device in the list. It will do this in the reverse order in which the
devices were initialized.

If the <system_devices> parameter is false then it would call all
devices. If it is true then it would call the suspend/resume of only
system devices. This parameter is provided because it is mandatory for
the PM service app to call this function for system devices. This is
because it cannot bind to them and call their suspend/resume functions
directly. For non-system devices, the PM service app can bind to thm
and has the flexibility to call whichever device it requires to call and
in the order it chooses to. If it chooses to call the suspend/resume
functions of non-system devices individually, then it would call this
function passing true for the <system_devices> parameter.

d) void device_resume_all(bool system_devices)
param system_devices
Boolean true for only the system devices; else all devices

Details:
The description is same as for device_suspend_all() except, this would
call the resume hook functions of devices and they would be called in
the same order as the devices were initialized.

API for device drivers:
Structure storing the hook functions. This structure is stored in the
device's "device" structure.
struct device_power_ops {
device_op_t suspend;
device_op_t resume;
}

The NO-OP function:
int device_pm_noop(struct device *unused)
return - always returns DEV_OK.

Details:
No-op function that does nothing and returns DEV_OK immediately. This
can be used to initialize hooks for which the device has no operation to do.

The hooks inside device_power_ops structure are by default initialized
with this function by the kernel. Device drivers which have specific
operations for the hooks would overwrite with a suspend and resume
functions during driver initialization.

a) void device_power_ops_configure(struct device *port,
device_op_t suspend_fn, device_op_t resume_fn)
param port
- device structure of driver instance
param suspend_fn
- Address of suspend function
param resume_fn
- Address of resume function

Details:
Initializes the hook functions in device_power_ops with the functions
passed as parameters. This function should be called by devices during
the time of initialization if they have a specific suspend or resume
function implementation. Drivers can also pass the no-op function as
parameter for any of the hooks it does not have an operation. If it
does not have any operation for both suspend and resume then it need not
call this function at all. This is because the hooks for the devices are
by default initialized with the no-op function by the kernel.


RFC [1/3] - SoC, CPU LPS, Tickless idle and Device power management

Thomas, Ramesh
 

***This part is merged***
https://gerrit.zephyrproject.org/r/#/c/148/
https://gerrit.zephyrproject.org/r/#/c/149/
https://gerrit.zephyrproject.org/r/#/c/150/
https://gerrit.zephyrproject.org/r/#/c/151/

Kernel SOC power management hook infrastructure in Zephyr
-----------------------------------------------------------------------
This infrastructure provides hooks at locations where the kernel goes to
idle to enable the PM service application to do suspend operations
around them.

This infrastructure can be used by power manager app to implement PM
policy and to put system to various power states. A sample PM
application is provided as an example to demonstrate how to use these
hooks and the states it uses (listed below) are for demonstration
purpose. It is up to the implementer of the PM service app to design their own.

1. LPS:
CPU is put in low power states like C2. The CPU states are not lost.
Woken up by any interrupt.

2. Deep Sleep:
The SoC is put in deep sleep state saving most power. In this state, CPU
power is off while SRAM contents are retained. Woken up by deep
sleep wake up events of SoC. On wake up, execution will resume from
reset vector.

3. Tickless Idle power saving:
Zephyr kernel has its own idling called Tickless idle. PM service can
take advantage of this by turning off peripherals to save more power
when the hook infrastructure notifies it before going to idle. It will
be notified again when kernel exits the tickless idle state when it can
restore states it altered.

The hook functions:
These functions must be implemented by the power management service app.

a) int _sys_soc_suspend(int32_t ticks)
param ticks:
- the upcoming kernel idle time

return:
- non-zero value if it uses its own idle or deep sleep. If a zero value
is returned, then kernel will enter its own idle.

Details:
This is called immediately before the kernel prepares to go into its
idle state. The PM service, based on the amount of idle time available,
chooses an appropriate power policy comparing the wake latencies involved.

For CPU low power states it would put the CPU in states like C2. For
SoC deep sleep states, it would do the required SoC specific operation.
In these, it would return a non-zero value indicating it has fully
handled the idle and the kernel will not enter its own idle.

For tickless idle power saving, the PM service app can turn off as many
peripherals it requires and then returns a zero value. The zero return
value would indicate to the kernel that it should do its own idle.

This function is entered with interrupts disabled. It should re-enable
interrupts if it does its own idle or deep sleep. If it returns zero
then it should not enable interrupts so the kernel can go to idle state
without interruption.

b) void _sys_soc_resume(void)

Details:
The main purpose of this hook is to notify PM service of exit from SoC
deep sleep state, CPU low power and tickless idle exit. Any states
altered at _sys_soc_suspend() should be restored in this function.

This hook function is called from 2 different locations in the kernel.
PM service will check its internal states to determine which state the
system recovering from.

Following are the 2 different locations where it called from:
1. At kernel start recovering from deep sleep or entering cold boot.
Deep sleep causes all CPU states to be lost so the system resumes at the
reset vector taking the same path as cold boot. Since kernel does not
save any state to identify whether it is recovering from cold boot or
deep sleep, it would call this function in both cases. PM service can
use SoC specific sticky registers that can retain values across deep
sleep to identify whether it is resuming from deep sleep. In the case
of cold boot, these registers would get reset.

If it is cold boot then this function should return immediately doing
nothing.

If it is recovering from deep sleep then it should restore states
including CPU registers and stack stored in _sys_soc_suspend().
Execution context should then switch to execution inside
_sys_soc_suspend() at the location where it put the system to deep sleep.

In this location, this function is called using a temporary stack that
is also used by interrupts. It is important that this function switches
to the stack that was saved during _sys_soc_suspend before interrupts
are enabled when returning from _sys_soc_suspend() to avoid interfering
with interrupt handlers use of this stack.

2. After the exit of tickless idle or a low power CPU state from the
context of the ISR that caused the exit. In this case, PM service will
restore altered states and return.

7781 - 7800 of 7929