Message-ID: <4863D97A.9090102@gmail.com>
Date:	Thu, 26 Jun 2008 19:01:30 +0100
From:	Jonathan Cameron <Jonathan.Cameron@...il.com>
To:	Jean Delvare <khali@...ux-fr.org>
CC:	linux-kernel@...r.kernel.org,
	spi-devel-general@...ts.sourceforge.net,
	LM Sensors <lm-sensors@...sensors.org>,
	Dmitry Torokhov <dtor@...l.ru>, Ben Dooks <ben@...ff.org>,
	mgross@...ux.intel.com, hmh@....eng.br,
	"Hans J. Koch" <hjk@...utronix.de>,
	Anton Vorontsov <avorontsov@...mvista.com>
Subject: Re: Accelerometer etc subsystem (Update on progress)

Dear All,

This email is mainly to give people an idea of current progress towards
a new
subsystem as discussed in the thread starting with
http://lkml.org/lkml/2008/5/20/135

Sorry for the mass list bombardment, but clearly some elements of this
discussion
will end up in various different territories.

Some elements of a prototype subsystem are in place. It draws very heavily
on parts of the input and hwmon subsystems diverging only where necessary.

The only test driver currently integrated is for an ST LIS3L02DQ
accelerometer
which has more than a few quirks to make it tricky to handle (and some what
sketchy documentation.) More chips will follow over next week or so but
hopefully the driver for this chip gives enough of an idea of how I envision
the system working to encourage discussion / advice.

Note that I haven't dealt with anywhere near all the possible locking issues
etc and am well aware that this needs to be done. Other cleanups that will
need to be done include working out the layout in sysfs to make it more
intuitive. Also sorry for the somewhat rough and ready nature of the
attached
patch (against 2.6.26-rc4)

Ring buffer design is a large part of the attached patch. I'm not sure if
I am going about this the right way. Basically, we need ring buffers with
almost no write latency but can waste plenty of time reading from them
(in general case - we do however want reading the last available value to be
fast). What is there works, but probably has at least a few nasty corner
cases that I haven't prevented.

Interfaces (these are per device) - at somepoint a procfs interface similar
       to that used in the input subsystem would make device querying
       simpler.

Sysfs -    Parameter Control - gain / offsets etc
    State control, turn interrupts on and off etc.
    Interrupt control parameters (threshold etc)
    Ring buffer parameters as relevant (currently fixed)
    Individual input reading (acceleration values here)
    Minor numbers for various chrdevs associated with this device.

chrdev-    3 types of chrdev at the moment
    Ring buffer events
    Ring buffer access (currently ripping data off the buffer only)
    Interrupt events - for lis3l02dq these are only threshold breaks

Functionality yet to be implemented.
    Polled based capture (use a peroidic timer if available)

    Hardware ring buffering for devices that support it (two level ring
buffer -
    hard and soft may be appropriate)

    A chrdev for polling of whole device (with timestamps etc).

    Composite interrupt handling (some devices allow logical combinations
    of different interrupt signals to be used as the trigger condition).

    Documenation ;)

    Cleaner solution to data alignment in the ring buffer (currently I'm
cheating
    and manually doing it)

    Lots lots more....

Anyhow, all comments welcome.  Can anyone think of a better name?
(I'm not keen on industrialio. It's too long if nothing else!
 It will do as a working title for now)

Thanks,

--

Jonathan Cameron


View attachment "indio.patch" of type "text/x-patch" (88444 bytes)

Powered by blists - more mailing lists