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

[Alan Cox <alan@linux.intel.com>]

> 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.

Not specifically - but for the most part it shouldn't matter. We have
interfaces like request_firmware() to load firmware and we have
interfaces for input devices and for 

> 2) Is there a standard way to integrate user space components with
> kernel side components.

Use the standard kernel interfaces. If specific processing is needed in
user space the to go into the kernel it needs to be such that those
interfaces can be used in an open manner (this normally comes up with
3D graphics hardware rather than input), either by documenting the
interface or providing an open implementation.

> 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. 

The ektf2136 driver currently getting tidied up provides both. You can
open it either as an input driver directly, or you can access raw event
data in a documented for and do clever things with the data and feed it
back to the input layer via uevent.

> 6) Are there any other major design concerns? 

We have an initial mpu3050 driver which provides basic functionality
(from Wistron/Intel), normal Linux practice would be to extend and
improve that.

> 7) Can an input device also have a character device interface for
> proprietary customization.

That depends what you mean and what for. Fundamentally there is no
reason a device cannot present multiple interfaces although you might
need to lock between them.

> +Programming the chip using /dev/mpu
> +----------------------------------
> +Programming of MPU3050 is done by first opening the /dev/mpu file and
> +then performing a series of IOCTLS on the handle returned.  The
> IOCTL codes can +be found in mpu.h.  Typically this is done by the
> mllite library in user +space.

Is this published with source or sufficient documentation for someone
to write their own ? Note btw the usual expectation would be that the
kernel driver uses request_firmware to load firmware as needed for that
part of the process.