Date:	Thu, 26 Jun 2008 19:26:39 +0100
From:	Jonathan Cameron <Jonathan.Cameron@...il.com>
To:	unlisted-recipients:; (no To-header on input)
CC:	linux-kernel@...r.kernel.org,
	spi-devel-general@...ts.sourceforge.net,
	LM Sensors <lm-sensors@...sensors.org>
Subject: Re: Accelerometer etc subsystem (Update on progress)

Sorry, forgot to include the headers in the original patch.  Obviously these
are very rough and ready at the moment and if nothing else their overall
layout isn't particularly logical.
> 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_headers.patch" of type "text/x-patch" (16883 bytes)

Powered by blists - more mailing lists