Re: [RFC PATCH 3/8] iio: core: Introduce new MOTION event

[Jonathan Cameron <jic23@kernel.org>]

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@intel.com>
>>> Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
>> 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@vger.kernel.org
>>> +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 :)
> 
> Daniel.
> 
> [1] https://source.android.com/devices/sensors/composite_sensors.html