lkml.org 
[lkml]   [2008]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [spi-devel-general] Accelerometer, Gyros and ADC's etc within the kernel.
    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@gmail.com
    irc://irc.freenode.net/bd2


    \
     
     \ /
      Last update: 2008-05-27 19:03    [W:0.035 / U:88.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site