On 10/11/2014 11:47 AM, Daniel Baluta wrote:
On Thu, Oct 9, 2014 at 10:31 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
On 06/10/14 15:17, Daniel Baluta wrote:
On 10/04/2014 04:12 PM, Jonathan Cameron wrote:
On 02/10/14 14:43, Daniel Baluta wrote:
This is to be used by drivers to signal detection of motion. We also
add some possible values for motion as IIO events modifiers:
* running
* jogging
* walking
* still
These values are supported by Frescale's MMA9553 sensor:
http://freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf
Signed-off-by: Daniel Baluta <daniel.baluta@xxxxxxxxx>
Signed-off-by: Irina Tirdea <irina.tirdea@xxxxxxxxx>
Hmm.. This is the interesting one.
Not immediately obvious how best to represent this stuff.
---
Documentation/ABI/testing/sysfs-bus-iio | 7 +++++++
drivers/iio/industrialio-core.c | 4 ++++
drivers/iio/industrialio-event.c | 1 +
include/linux/iio/types.h | 7 ++++++-
4 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio
b/Documentation/ABI/testing/sysfs-bus-iio
index d760b02..070346d 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -808,6 +808,13 @@ Description:
number or direction is not specified, applies to all channels of
this type.
+What: /sys/.../events/in_activity_motion_either_en
+KernelVersion: 3.17
+Contact: linux-iio@xxxxxxxxxxxxxxx
+Description:
+ Enables or disables motion detection. Each time motion is detected an
+ event of this type will be generated.
+
The either bit seems a bit random but I can see there is no particularly obvious
alternative.
I wonder if introducing a new IIO_EV_DIR_NONE event direction type would make
sense. In this case the sysfs attribute will drop event direction text from its
name (e.g /sys/.../events/in_activity_motion_en)
We really need a clean way of representing a multilevel 'state change' like this.
Looking at the event code, I almost wonder if we would be better using the
direction element for running, walking etc rather than a modifier.
When pushing events code to userspace the modifier seemed to be the only option.
Having said that we will probably also get devices where this is polled rather
than
event. 'What activity is currently going on?'
Adding IIO_EV_INFO_VALUE bit, would create an attribute
/sys/.../events/in_activity_motion_either_value that could expose the current
activity going on.
If we take that view modifiers make sense as it becomes
'Is the user running?' Perhaps even offering a confidence interval, e.g units as
percentage
in_activity_running_input 0..100
in_activity_walking_input 0..100
etc
Then our event becomes a state change event (yup we'll need to add that)
/events/in_activity_walking_rising_en will then cause events when the percentage
confidence on a state rises above the provided threshold or goes above it
(default of 50% perhaps on devices which only report one state).
/events/in_activity_walking_falling_en will do the leaving case.
This is a very nice idea and it will also offer more flexibility. I am not sure
about the use case of confidence interval but using 0 and 100 will do the trick
for us.
Sure, feel free to propose something else. We could define a confidence interval
that counts as 'we think it is this'. Basically just use values of 0 or 100 when
there is no explicit indication of the confidence available. Not sure what
you do get ;)
We will use this interface for implementation of significant motion in Android's
HAL. [1]
I will experiment more with how IIO attributes work and I will send a v2
using direction instead of modifier for activity type (running, walking etc).
Note these are just some quick initial thoughts on alternative methods.
I'll want to think on this more and get responses from more interested
parties!
Thanks a lot for your time!
You are welcome. Funnily enough I rather enjoy trying to think of ways to
handle new 'weird' hardware in a consistent fashion :)
We have already sent a second proposal :).
http://marc.info/?l=linux-iio&m=141285801717857&w=2
We are also hoping to get more opinions from other parties.
CC'ing Karol from Samsung :).
Daniel.
Thanks for the info.
In my case I have to figure out what is really needed between hw and
driver first.
The existing android driver has given a data blob to user space as
concerns new
sensor classes. Please, give a few days.
Karol
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
