RE: [PATCH 01/11] misc: inv_mpu primary header file and README file.

[Nathan Royer]

> > > accel/bma150.c
> > An input driver exists for that one. (cc'd Eric)
>
> [Two input drivers - bma023 which I posted covers it too ;)]
>
> > > # sensors - compass
> > > compass/ak8975.c
>
> We have a driver for this (I posted a while back)
>
> > > compass/ak8972.c
>
> > > compass/ami30x.c
>
> AMI304 is identical to the AK8974 which we already have - Gram Hsieh
> posted patches for this a while ago

It seems that some sensors are in input and but that most are in iio.
Obviously I don't want to dissent with both and put ours in misc, so how
do we make this better?  Should we work on cleaning this up.  If so should
we start moving the drivers that are in input to iio.

If this is the right thing to do, I could start working on merging the
current mpu3050 input interface and our misc interface to the iio
interface.  I'm still trying to wrap my head around the iio framework, but
I think one of the things I need is a uinput like interface for iio
(perhaps it exists, I just haven't figured it out yet).  If the DMP is
used, a buffer for the FIFO data would be created, and user space would be
responsible to push the sensor data back to iio after sensor fusion and
calibration.  Without the DMP, each sensor driver would act independently
providing their own raw data.

We still need a way to read and write registers and DMP memory during
runtime from user space.
--
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/