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

[Nathan Royer]

> > 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.
>
> IIO provides a lot more flexibility and is rather newer, input provides
> a more focussed interface. In some cases it may make sense to provide
> different interfaces to each (eg atomspheric pressure doesn't fit well
> into input, but 3 axis accelerometers fit perfectly)
>
> > We still need a way to read and write registers and DMP memory during
> > runtime from user space.
>
> You probably want a driver for the MPU itself whih provides the
> needed glue and also control interfaces (firmware load etc). That may
> well be a drivers/misc item as I imagine that part is quite unique and
> specialised.

If I understand you correctly, you are suggesting that we create two
drivers for the mpu3050 part.  An MPU (Motion Processing Unit) driver and
a standalone Gyroscope driver.  The MPU if present would turn each sensor
(accel, compass, gyro, pressure) into an MPU slave, load and configure the
firmware, and provide a user space interface for customization and runtime
communication with the Hideously Complicated Algorithms (HCA's).

Each sensor driver would have two operating modes, standalone, and slave
to the MPU trying to re-use as much code as possible.  Current drivers
that have a standalone interface would need the slave interface added, and
those that we've written would need the stand alone interface added.
--
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/