On 07/01/11 04:09, Greg KH wrote: > On Thu, Jun 30, 2011 at 07:18:17PM -0700, Nathan Royer wrote: >> This files defines the userspace interface and how to integrate it into a >> platform. >> >> Signed-off-by: Nathan Royer <nroyer@xxxxxxxxxxxxxx> >> --- >> >> This is the first of many patch files for the inv_mpu driver in its current >> state. This is our first time submitting this driver, so I expect there to be >> a lot wrong with it, and expect to need to fix many things. >> >> The inv_mpu driver attepts to implement a Motion Processing Unit interface. As >> a unit, an accelerometer, magnetometer, gyroscope, and/or altimiter data is >> fused together to produce calibrated data and a quaternion. >> >> The inv_mpu driver interface is currently implemented as a misc device, but may >> need to change to include both sysfs attributes and input devices. I think >> that we will continue to need the ioctl interface, but many of the ioctls can >> be replace by attributes and/or input devices. >> >> The mpu3050 has an i2c master interface designed to control an accelerometer >> and a Digital Motion Processor (DMP) used to perform sensor fusion on the >> gyroscope and accelerometer. This data is then read out of the mpu3050 fifo >> and sent to userspace for distribution and optional propritary processing, such >> as fusion with a compass to produce a 9 axis quaternion. >> >> Some question I have at the start are: >> 1) Is there a master design or standard interface for Motion Processing >> devices, specifically ones that do calibration, sensor fusion, and or have a >> micro-controller to do some of this work. Some of Analog's parts are doing a very basic form of this (bit of integration etc). Ultimately in their case it is transparent, so they just look like additional data channels. Here it looks more sophisticated. >> 2) Is there a standard way to integrate user space components with kernel side >> components. >> 3) Should data be pushed back to the driver from userspace, and made available >> as an input device or should it remain as a character device. Depends on the use case. If you have to do userspace processing, then uinput does this nicely. >> 4) Can a 4 element quaternion be added to input.h: >> ABS_QUATERNION_1 ABS_QUATERNION_I ABS_QUATERNION_J ABS_QUATERNION_K >> for <1, i, j, k> >> 5) Should we instead use a rotation vector as defined in the Android sensor: >> http://developer.android.com/reference/android/hardware/SensorEvent.html If you hardware is producing quaternions directly you are not going to want to the necessary sin / cos in kernel. Trivial in userspace though. >> 6) Are there any other major design concerns? The big one Alan and Jean have commented on. This device just has slave i2c devices they should have their own drivers if at all possible. > > Shouldn't you be using the iio subsystem for the kernel/user interface > as I think it handles most of this for you already, right? Few bits we haven't seen before, but nothing that can't be easily added. We do have a usual question here of whether this is better as an input device though. Dmitry, what is your view on this one? Certainly doesn't want to end up in misc. Alan (in other branch) has highlighted an existing driver for the mpu part. > >> 7) Can an input device also have a character device interface for proprietary >> customization. > > What do you mean by this? > > greg k-h > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
