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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: indio_headers.patch Type: text/x-patch Size: 16882 bytes Desc: not available Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20080626/7d75e205/attachment.bin
