Re: [spi-devel-general] Accelerometer, Gyros and ADC's etc withinthe kernel.

[Anton Vorontsov]

On Tue, May 27, 2008 at 05:50:21PM +0100, Ben Dooks wrote:
> On Tue, May 27, 2008 at 08:44:15PM +0400, Anton Vorontsov wrote:
> > Hi Jonathan,
> > 
> > On Tue, May 20, 2008 at 11:04:01AM +0100, Jonathan Cameron wrote:
> > > This email is basically a request for opinions on how and where such sensors
> > > should be integrated into the kernel.
> > > 
> > > To set the scene...
> > > 
> > > Increasing numbers of embedded devices are being supplied attached MEMS
> > > devices (www.xbow.com imote2 etc). Along with more traditional sensors such
> > > as ADC's not being used for hardware monitoring, these do not really 
> > > seem to
> > > fit with in an particular subsystem of the kernel.  A previous 
> > > discussion on
> > > lkml in 2006 considered the accelerometers to be found within some laptop
> > > hard drives, but I haven't been able to track down any more general 
> > > discussions
> > > of such non hardware monitoring sensors.
> > > 
> > > The obvious possibilities are:
> > > 
> > > * To place the various drivers within the spi / i2c etc subsystems as 
> > > relevant.
> > > 
> > > * To place within the hwmon subsystem as this is probably closest.
> > > (there is already at least one straight ADC driver in hwmon)
> > > 
> > > * To create a new subsystem, or perhaps merely sysfs class to contain these
> > >   elements.
> > > 
> > > Typical requirements within an application include simply polling for 
> > > current
> > > readings, and using device triggered interrupts to grab data 
> > > continuously to a
> > > ring buffer, for collection by suitable userspace code.  Obviously it 
> > > would be
> > > desirable to standardize sysfs controls for various calibration 
> > > parameters as
> > > much as possible across the various devices.
> 
> The two drivers i've seen so far use the input subsystem to report
> their data to the user. I'm working on an driver for the SMB380 which
> can be both i2c and spi.
>  
> > Also, I'd mention that most ADC devices could report in "bunched" mode,
> > i.e.
> > 
> > 1. Request ADC readings from pins X, Y, Z1, Z2.
> > 2. Wait for single IRQ
> > 3. Read all the results
> > 
> > At handhelds.org, we've wrote quite good (I think) ADC subsystem,
> > that keeps in mind ADC capabilities. It implements two interfaces:
> > in-kernel (e.g. for touchscreen drivers), and userspace interface via
> > sysfs. I was planning to implement drivers/input/ interface too.
> 
> handhelds.org's track history of getting things into the kernel
> is poor.

Yes, mostly. Because lack of human resources. But something gets done
anyway, e.g. drivers/power/ is already in the mainline. Philipp Zabel is
doing great work for the HTC Magician support (already in mainline, too).

I think there are only few of us who think that mainlining is important,
this is bad. But the thinking improves as times goes by.

So, don't be so pessimistic. :-)

-- 
Anton Vorontsov
email: cbouatmailru@xxxxxxxxx
irc://irc.freenode.net/bd2
--
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/