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

[Karol Wrona]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/