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.patch Type: text/x-patch Size: 88443 bytes Desc: not available Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20080626/4cdc484f/attachment.bin
