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