Topics

[RFC PATCH 2/6] sensor: add device config helpers


Vlad Dogaru <vlad.dogaru@...>
 

Define some configuration structures and macros that can be used in
device configuration. These usage scenarios are as follows:

* device drivers will use DECLARE_* macros in their device
configuration structures and GET_* macros in the init functions;

* application code will use SENSOR_TRIG_* to fill in the device
configuration structures.

We also define a convenient wrapper for starting a new fiber based on a
given configuration.

Change-Id: I3a897999175b14a4cd1111da4c26434741294e52
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/sensor.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/include/sensor.h b/include/sensor.h
index 918326a..8312b5a 100644
--- a/include/sensor.h
+++ b/include/sensor.h
@@ -190,6 +190,18 @@ enum sensor_attribute {
SENSOR_ATTR_CALIB_TARGET,
};

+enum sensor_trigger_mode {
+ SENSOR_TRIG_MODE_NONE,
+ SENSOR_TRIG_MODE_OWN,
+ SENSOR_TRIG_MODE_GLOBAL,
+};
+
+struct fiber_config {
+ void *fiber_stack;
+ unsigned int fiber_stack_size;
+ unsigned int fiber_priority;
+};
+
typedef void (*sensor_trigger_handler_t)(struct device *dev,
struct sensor_trigger *trigger);

@@ -334,6 +346,15 @@ static inline int sensor_channel_get(struct device *dev,
return api->channel_get(dev, chan, val);
}

+static inline nano_thread_id_t
+sensor_fiber_start(const struct fiber_config *cfg,
+ nano_fiber_entry_t entry, int arg1, int arg2,
+ unsigned options)
+{
+ return fiber_start(cfg->fiber_stack, cfg->fiber_stack_size,
+ entry, arg1, arg2, cfg->fiber_priority,
+ options);
+}

#ifdef CONFIG_SENSOR_DELAYED_WORK
/**
@@ -425,6 +446,29 @@ static inline void sensor_degrees_to_rad(int32_t d, struct sensor_value *rad)
rad->val2 = ((int64_t)d * SENSOR_PI / 180LL) % 1000000LL;
}

+#define DECLARE_SENSOR_TRIG_CONFIG \
+ enum sensor_trigger_mode trig_mode; \
+ struct fiber_config fiber_config
+
+#define SENSOR_TRIG_OWN_FIBER(stack, prio) \
+ .trig_mode = SENSOR_TRIG_MODE_OWN, \
+ .fiber_config = { \
+ .fiber_stack = (stack), \
+ .fiber_stack_size = sizeof(stack), \
+ .fiber_priority = (prio), \
+ }
+
+#define SENSOR_TRIG_GLOBAL_FIBER \
+ .trig_mode = SENSOR_TRIG_MODE_GLOBAL, \
+ .fiber_config = { \
+ .fiber_stack = NULL, \
+ .fiber_stack_size = 0, \
+ .fiber_priority = 0, \
+ }
+
+#define GET_SENSOR_TRIG_MODE(conf) ((conf)->trig_mode)
+#define GET_SENSOR_FIBER_CONFIG(conf) ((conf)->fiber_config)
+
#ifdef __cplusplus
}
#endif
--
1.9.1


Vlad Dogaru <vlad.dogaru@...>
 

On Mon, Apr 25, 2016 at 12:59:57PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,

Define some configuration structures and macros that can be used in
device configuration. These usage scenarios are as follows:

* device drivers will use DECLARE_* macros in their device
configuration structures and GET_* macros in the init functions;

* application code will use SENSOR_TRIG_* to fill in the device
configuration structures.

We also define a convenient wrapper for starting a new fiber based on a
given configuration.

Change-Id: I3a897999175b14a4cd1111da4c26434741294e52
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/sensor.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/include/sensor.h b/include/sensor.h
index 918326a..8312b5a 100644
--- a/include/sensor.h
+++ b/include/sensor.h
@@ -190,6 +190,18 @@ enum sensor_attribute {
SENSOR_ATTR_CALIB_TARGET,
};
+enum sensor_trigger_mode {
+ SENSOR_TRIG_MODE_NONE,
+ SENSOR_TRIG_MODE_OWN,
+ SENSOR_TRIG_MODE_GLOBAL,
+};
+
+struct fiber_config {
Since it's part of public sensor API, rename it to: struct
sensor_fiber_config
If it stays here, then yeah, it makes sense to prefix it with "sensor_".

The question is if other subsystems would benefit from such a structure.
As it's defined now, there is nothing sensor specific about it or the
helper function that starts a fiber. Should I move them to a system
header so others can use them?


+ void *fiber_stack;
+ unsigned int fiber_stack_size;
+ unsigned int fiber_priority;
+};
+
typedef void (*sensor_trigger_handler_t)(struct device *dev,
struct sensor_trigger *trigger);
@@ -334,6 +346,15 @@ static inline int sensor_channel_get(struct device *dev,
return api->channel_get(dev, chan, val);
}
+static inline nano_thread_id_t
+sensor_fiber_start(const struct fiber_config *cfg,
+ nano_fiber_entry_t entry, int arg1, int arg2,
+ unsigned options)
+{
+ return fiber_start(cfg->fiber_stack, cfg->fiber_stack_size,
+ entry, arg1, arg2, cfg->fiber_priority,
+ options);
+}
#ifdef CONFIG_SENSOR_DELAYED_WORK
/**
@@ -425,6 +446,29 @@ static inline void sensor_degrees_to_rad(int32_t d, struct sensor_value *rad)
rad->val2 = ((int64_t)d * SENSOR_PI / 180LL) % 1000000LL;
}
+#define DECLARE_SENSOR_TRIG_CONFIG \
+ enum sensor_trigger_mode trig_mode; \
+ struct fiber_config fiber_config
+
+#define SENSOR_TRIG_OWN_FIBER(stack, prio) \
+ .trig_mode = SENSOR_TRIG_MODE_OWN, \
+ .fiber_config = { \
+ .fiber_stack = (stack), \
+ .fiber_stack_size = sizeof(stack), \
+ .fiber_priority = (prio), \
+ }
+
+#define SENSOR_TRIG_GLOBAL_FIBER \
+ .trig_mode = SENSOR_TRIG_MODE_GLOBAL, \
+ .fiber_config = { \
+ .fiber_stack = NULL, \
+ .fiber_stack_size = 0, \
+ .fiber_priority = 0, \
+ }
+
+#define GET_SENSOR_TRIG_MODE(conf) ((conf)->trig_mode)
+#define GET_SENSOR_FIBER_CONFIG(conf) ((conf)->fiber_config)
SENSOR_ prefixed
Will do.


+
#ifdef __cplusplus
}
#endif
Thanks,
Vlad


Tomasz Bursztyka
 

Hi Vlad,

Define some configuration structures and macros that can be used in
device configuration. These usage scenarios are as follows:

* device drivers will use DECLARE_* macros in their device
configuration structures and GET_* macros in the init functions;

* application code will use SENSOR_TRIG_* to fill in the device
configuration structures.

We also define a convenient wrapper for starting a new fiber based on a
given configuration.

Change-Id: I3a897999175b14a4cd1111da4c26434741294e52
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/sensor.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/include/sensor.h b/include/sensor.h
index 918326a..8312b5a 100644
--- a/include/sensor.h
+++ b/include/sensor.h
@@ -190,6 +190,18 @@ enum sensor_attribute {
SENSOR_ATTR_CALIB_TARGET,
};

+enum sensor_trigger_mode {
+ SENSOR_TRIG_MODE_NONE,
+ SENSOR_TRIG_MODE_OWN,
+ SENSOR_TRIG_MODE_GLOBAL,
+};
+
+struct fiber_config {
Since it's part of public sensor API, rename it to: struct
sensor_fiber_config

+ void *fiber_stack;
+ unsigned int fiber_stack_size;
+ unsigned int fiber_priority;
+};
+
typedef void (*sensor_trigger_handler_t)(struct device *dev,
struct sensor_trigger *trigger);

@@ -334,6 +346,15 @@ static inline int sensor_channel_get(struct device *dev,
return api->channel_get(dev, chan, val);
}

+static inline nano_thread_id_t
+sensor_fiber_start(const struct fiber_config *cfg,
+ nano_fiber_entry_t entry, int arg1, int arg2,
+ unsigned options)
+{
+ return fiber_start(cfg->fiber_stack, cfg->fiber_stack_size,
+ entry, arg1, arg2, cfg->fiber_priority,
+ options);
+}

#ifdef CONFIG_SENSOR_DELAYED_WORK
/**
@@ -425,6 +446,29 @@ static inline void sensor_degrees_to_rad(int32_t d, struct sensor_value *rad)
rad->val2 = ((int64_t)d * SENSOR_PI / 180LL) % 1000000LL;
}

+#define DECLARE_SENSOR_TRIG_CONFIG \
+ enum sensor_trigger_mode trig_mode; \
+ struct fiber_config fiber_config
+
+#define SENSOR_TRIG_OWN_FIBER(stack, prio) \
+ .trig_mode = SENSOR_TRIG_MODE_OWN, \
+ .fiber_config = { \
+ .fiber_stack = (stack), \
+ .fiber_stack_size = sizeof(stack), \
+ .fiber_priority = (prio), \
+ }
+
+#define SENSOR_TRIG_GLOBAL_FIBER \
+ .trig_mode = SENSOR_TRIG_MODE_GLOBAL, \
+ .fiber_config = { \
+ .fiber_stack = NULL, \
+ .fiber_stack_size = 0, \
+ .fiber_priority = 0, \
+ }
+
+#define GET_SENSOR_TRIG_MODE(conf) ((conf)->trig_mode)
+#define GET_SENSOR_FIBER_CONFIG(conf) ((conf)->fiber_config)
SENSOR_ prefixed

+
#ifdef __cplusplus
}
#endif


Benjamin Walsh <benjamin.walsh@...>
 

On Mon, Apr 25, 2016 at 01:58:12PM +0300, Vlad Dogaru wrote:
On Mon, Apr 25, 2016 at 12:59:57PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,

Define some configuration structures and macros that can be used in
device configuration. These usage scenarios are as follows:

* device drivers will use DECLARE_* macros in their device
configuration structures and GET_* macros in the init functions;

* application code will use SENSOR_TRIG_* to fill in the device
configuration structures.

We also define a convenient wrapper for starting a new fiber based on a
given configuration.

Change-Id: I3a897999175b14a4cd1111da4c26434741294e52
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/sensor.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/include/sensor.h b/include/sensor.h
index 918326a..8312b5a 100644
--- a/include/sensor.h
+++ b/include/sensor.h
@@ -190,6 +190,18 @@ enum sensor_attribute {
SENSOR_ATTR_CALIB_TARGET,
};
+enum sensor_trigger_mode {
+ SENSOR_TRIG_MODE_NONE,
+ SENSOR_TRIG_MODE_OWN,
+ SENSOR_TRIG_MODE_GLOBAL,
+};
+
+struct fiber_config {
Since it's part of public sensor API, rename it to: struct
sensor_fiber_config
If it stays here, then yeah, it makes sense to prefix it with "sensor_".

The question is if other subsystems would benefit from such a structure.
As it's defined now, there is nothing sensor specific about it or the
helper function that starts a fiber. Should I move them to a system
header so others can use them?
Were you envisionning having this as a "device" type of fiber, or were
you thinking having this as an even more generic concept ?


+ void *fiber_stack;
+ unsigned int fiber_stack_size;
+ unsigned int fiber_priority;
+};
+
typedef void (*sensor_trigger_handler_t)(struct device *dev,
struct sensor_trigger *trigger);
@@ -334,6 +346,15 @@ static inline int sensor_channel_get(struct device *dev,
return api->channel_get(dev, chan, val);
}
+static inline nano_thread_id_t
+sensor_fiber_start(const struct fiber_config *cfg,
+ nano_fiber_entry_t entry, int arg1, int arg2,
+ unsigned options)
+{
+ return fiber_start(cfg->fiber_stack, cfg->fiber_stack_size,
+ entry, arg1, arg2, cfg->fiber_priority,
+ options);
+}
#ifdef CONFIG_SENSOR_DELAYED_WORK
/**
@@ -425,6 +446,29 @@ static inline void sensor_degrees_to_rad(int32_t d, struct sensor_value *rad)
rad->val2 = ((int64_t)d * SENSOR_PI / 180LL) % 1000000LL;
}
+#define DECLARE_SENSOR_TRIG_CONFIG \
+ enum sensor_trigger_mode trig_mode; \
+ struct fiber_config fiber_config
+
+#define SENSOR_TRIG_OWN_FIBER(stack, prio) \
+ .trig_mode = SENSOR_TRIG_MODE_OWN, \
+ .fiber_config = { \
+ .fiber_stack = (stack), \
+ .fiber_stack_size = sizeof(stack), \
+ .fiber_priority = (prio), \
+ }
+
+#define SENSOR_TRIG_GLOBAL_FIBER \
+ .trig_mode = SENSOR_TRIG_MODE_GLOBAL, \
+ .fiber_config = { \
+ .fiber_stack = NULL, \
+ .fiber_stack_size = 0, \
+ .fiber_priority = 0, \
+ }
+
+#define GET_SENSOR_TRIG_MODE(conf) ((conf)->trig_mode)
+#define GET_SENSOR_FIBER_CONFIG(conf) ((conf)->fiber_config)
SENSOR_ prefixed
Will do.


+
#ifdef __cplusplus
}
#endif
Thanks,
Vlad
--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Benjamin Walsh <benjamin.walsh@...>
 

On Fri, Apr 22, 2016 at 01:15:59AM +0300, Vlad Dogaru wrote:
Define some configuration structures and macros that can be used in
device configuration. These usage scenarios are as follows:

* device drivers will use DECLARE_* macros in their device
configuration structures and GET_* macros in the init functions;

* application code will use SENSOR_TRIG_* to fill in the device
configuration structures.

We also define a convenient wrapper for starting a new fiber based on a
given configuration.

Change-Id: I3a897999175b14a4cd1111da4c26434741294e52
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/sensor.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/include/sensor.h b/include/sensor.h
index 918326a..8312b5a 100644
--- a/include/sensor.h
+++ b/include/sensor.h
@@ -190,6 +190,18 @@ enum sensor_attribute {
SENSOR_ATTR_CALIB_TARGET,
};

+enum sensor_trigger_mode {
+ SENSOR_TRIG_MODE_NONE,
+ SENSOR_TRIG_MODE_OWN,
+ SENSOR_TRIG_MODE_GLOBAL,
+};
+
+struct fiber_config {
+ void *fiber_stack;
+ unsigned int fiber_stack_size;
+ unsigned int fiber_priority;
+};
+
typedef void (*sensor_trigger_handler_t)(struct device *dev,
struct sensor_trigger *trigger);

@@ -334,6 +346,15 @@ static inline int sensor_channel_get(struct device *dev,
return api->channel_get(dev, chan, val);
}

+static inline nano_thread_id_t
+sensor_fiber_start(const struct fiber_config *cfg,
+ nano_fiber_entry_t entry, int arg1, int arg2,
+ unsigned options)
+{
+ return fiber_start(cfg->fiber_stack, cfg->fiber_stack_size,
+ entry, arg1, arg2, cfg->fiber_priority,
+ options);
+}

#ifdef CONFIG_SENSOR_DELAYED_WORK
/**
@@ -425,6 +446,29 @@ static inline void sensor_degrees_to_rad(int32_t d, struct sensor_value *rad)
rad->val2 = ((int64_t)d * SENSOR_PI / 180LL) % 1000000LL;
}

+#define DECLARE_SENSOR_TRIG_CONFIG \
^^^^^^^
DEFINE ? SENSOR_ prefix ?

+ enum sensor_trigger_mode trig_mode; \
+ struct fiber_config fiber_config
+
+#define SENSOR_TRIG_OWN_FIBER(stack, prio) \
+ .trig_mode = SENSOR_TRIG_MODE_OWN, \
+ .fiber_config = { \
+ .fiber_stack = (stack), \
+ .fiber_stack_size = sizeof(stack), \
+ .fiber_priority = (prio), \
+ }
+
+#define SENSOR_TRIG_GLOBAL_FIBER \
+ .trig_mode = SENSOR_TRIG_MODE_GLOBAL, \
+ .fiber_config = { \
+ .fiber_stack = NULL, \
+ .fiber_stack_size = 0, \
+ .fiber_priority = 0, \
+ }
+
+#define GET_SENSOR_TRIG_MODE(conf) ((conf)->trig_mode)
+#define GET_SENSOR_FIBER_CONFIG(conf) ((conf)->fiber_config)
+
#ifdef __cplusplus
}
#endif
--
1.9.1


Vlad Dogaru <vlad.dogaru@...>
 

On Tue, Apr 26, 2016 at 01:06:25PM -0400, Benjamin Walsh wrote:
On Mon, Apr 25, 2016 at 01:58:12PM +0300, Vlad Dogaru wrote:
On Mon, Apr 25, 2016 at 12:59:57PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,

Define some configuration structures and macros that can be used in
device configuration. These usage scenarios are as follows:

* device drivers will use DECLARE_* macros in their device
configuration structures and GET_* macros in the init functions;

* application code will use SENSOR_TRIG_* to fill in the device
configuration structures.

We also define a convenient wrapper for starting a new fiber based on a
given configuration.

Change-Id: I3a897999175b14a4cd1111da4c26434741294e52
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/sensor.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/include/sensor.h b/include/sensor.h
index 918326a..8312b5a 100644
--- a/include/sensor.h
+++ b/include/sensor.h
@@ -190,6 +190,18 @@ enum sensor_attribute {
SENSOR_ATTR_CALIB_TARGET,
};
+enum sensor_trigger_mode {
+ SENSOR_TRIG_MODE_NONE,
+ SENSOR_TRIG_MODE_OWN,
+ SENSOR_TRIG_MODE_GLOBAL,
+};
Since it's part of public sensor API, rename it to: struct
sensor_fiber_config
If it stays here, then yeah, it makes sense to prefix it with "sensor_".

The question is if other subsystems would benefit from such a structure.
As it's defined now, there is nothing sensor specific about it or the
helper function that starts a fiber. Should I move them to a system
header so others can use them?
Were you envisionning having this as a "device" type of fiber, or were
you thinking having this as an even more generic concept ?
I've left the rest of the structure and the helper that uses it below
and trimmed the rest of the code for clarity. There is nothing about
these that is sensor- or device-specific (well, besides the name, but
that I will change).

The caller can still supply their own entry point and arguments. So it
is a generic concept. I will post a patch for it.

+
+struct fiber_config {
+ void *fiber_stack;
+ unsigned int fiber_stack_size;
+ unsigned int fiber_priority;
+};

+static inline nano_thread_id_t
+sensor_fiber_start(const struct fiber_config *cfg,
+ nano_fiber_entry_t entry, int arg1, int arg2,
+ unsigned options)
+{
+ return fiber_start(cfg->fiber_stack, cfg->fiber_stack_size,
+ entry, arg1, arg2, cfg->fiber_priority,
+ options);
+}
Thanks,
Vlad