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