[spi-devel-general] [Industrial I/O] [0/13] RFC: IIO v3 patchset
Dear All, Sorry this has been so long in coming, it has been a busy couple of months. Summary of what IIO is about: The Industrial I/O (name open to suggestions) subsystem is the result of discussions on LKML about suitable facilities in the kernel for the handling of Analog to Digital Converters (ADCs) and the huge classes of sensor that act in similar fashion (digital accelerometers etc). The intention is that this may also provide a home for DACs as a lot of chips have both functions. The sort of devices we are talking typically communicate over I2C or SPI buses though drivers for rs232 devices etc are definitely on the cards. Basically we are interested in devices where direct memory mapped access is not possible. My particular motivation was to produce an adaptable data capture platform and, seeing as that's what is paying the bills, it has been the initial focus of my efforts. The RFCs below include the question of what other facilities should be included as options in this system. For discussion of why these don't fit within existing subsystems see http://lkml.org/lkml/2008/5/20/135 and the rest of the associated thread. The design is intended to allow a disparate set of drivers providing whatever subset of functionality people have uses for. Hence, the intention is that it is not necessary or even desirable to support as much as the example drivers provided here. The system is designed to allow everything from simple drivers providing sysfs based reading of individual channels to the level of complexity seen in the sca3000 accelerometer driver found in patch 11. To this end any final submission will include at least one example of a minimal driver. I'm still fairly new to kernel coding so have doubtlessly made many mistakes and non optimal decisions within this code. So, whilst this is intended primarily to feed a discussion of the overall framework, I would be grateful to receive any more specific comments on the code! Particularly welcome are any suggestions that will result in reductions in code length without loss of functionality as this is still rather larger than would be ideal! As ever, thanks to the numerous people who commented on the last version posted and those who have been testing the various intermediate versions (Marcelo Pias in particular.) Contents: [1/13] The Industrial I/O core: The core registration and event handling functionality of IIO. [2/13] The Industrial I/O core - ring buffer support: Adds ring buffer handling to the IIO core. [3/13] IIO: Software ring buffer implementation. An example software ring buffer module. [4/13] The Industrial I/O core - trigger support Adds trigger support to the IIO core. [5/13] IIO: Periodic real time clock based trigger. An example of IIO trigger supplying driver. [6/13] IIO: Proof of concept GPIO based IIO trigger A very simple GPIO based trigger suitable for external synchronization. [7/13] IIO: Maxim MAX1363 driver Driver for the the MAX1363 ADC chip (core functionality) [8/13] IIO: Maxim MAX1363 driver (ring buffer support) Add triggered software ring buffer support to the driver [9/13] IIO: ST LIS3L02DQ 3d accelerometer driver via SPI (core) Driver for the ST LIS3L02DQ accelerometer (SPI only) [10/13] IIO: ST LIS3L02DQ 3d accelerometer driver via SPI (ring) Add triggered software ring buffer support and a data ready based trigger to the device. [11/13] IIO: VTI SCA3000 3d accelerometer driver. Driver for the VTI SCA3000 range of accelerometers. [12/13] IIO: Documentation Whilst most documentation related to IIO is contained as kernel doc comments within the source code, a brief overview of what it does and discussions of elements of individual drivers are provided in Documentation/industrialio. [13/13] IIO: Example user space ring buffer access. Simple example program to illustrate how a user space application can interact with the ring buffer functionality of IIO (this includes event handling). The example used uses the datardy trigger of the lis3l02dq to drive the filling of a software ring buffer from the lis3l02dq device. Overview of changes: * Introduction of trigger drivers to allow more flexible sampling strategies and separate out the periodic RTC element (as only one example of a trigger driver.) New triggers provided as example / proofs of concept are GPIO based for external sync and data ready on the lis3l02dq (to act as example of a unified iio:trigger / iio:device driver) * Far more modular design: - The core now acts as a registration system providing sysfs class handling and registration of chrdevs. T
Re: [spi-devel-general] [Industrial I/O] [0/13] RFC: IIO v3 patchset
> have both functions. The sort of devices we are talking typically > communicate over I2C or SPI buses though drivers for rs232 devices etc are > definitely on the cards. Basically we are interested in devices where direct > memory mapped access is not possible. We have I2C and SPI drivers so I assume you will use the lower layers of the stacks to do this ? > For discussion of why these don't fit within existing subsystems see > http://lkml.org/lkml/2008/5/20/135 and the rest of the associated thread. I don't see much there which says why you can't unify all this in a user space library. For RS232/423/.. devices you can go this path if you want (but I would keep it all in userspace anyway) as you can use a line discipline to sit on top of the port and provide another interface (eg the way PPP does) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [Industrial I/O] [0/13] RFC: IIO v3 patchset
Dear Alan, >> have both functions. The sort of devices we are talking typically >> communicate over I2C or SPI buses though drivers for rs232 devices etc are >> definitely on the cards. Basically we are interested in devices where direct >> memory mapped access is not possible. > > We have I2C and SPI drivers so I assume you will use the lower layers of > the stacks to do this ? Yes, in much the same way that for example hwmon is built on top of these (amongst other interfaces) > >> For discussion of why these don't fit within existing subsystems see >> http://lkml.org/lkml/2008/5/20/135 and the rest of the associated thread. > I don't see much there which says why you can't unify all this in a user > space library. Indeed, that was an option considered at the time and the majority of that discussion focused on how to do things in a similar way to existing similar kernel subsystems. Perhaps this question needs further clarification. Much of the stuff provided in this initial patch set could indeed be provided by a fairly complex user space library. I get the feeling this rest of this response is going to look pretty familiar. Though as I have never attempted to code anything other than simple userspace drivers I suspect others may have more detailed responses. These are in no particular order. I believe the principle argument in favour of user space drivers is that of enhanced stability as they are unlikely to be able to bring the kernel down. This advantage is indeed valid here. The other advantage is that the number of copies required to get data to and from hardware are reduced. For the devices considered here a userspace driver would have to go via one of the chrdev interfaces and neither i2c-dev or spidev are able to support mmap ed interfaces. The problems I can forsee (or have encountered) with user space drivers for this sort of device: * In many cases the ADCs form part of more complex devices which already have a support within the kernel. (e.g. PMICs such as those supported by the DA903x mfd driver) and as such any additional interface will require at least some kernel parts. Other places I've seen ADCs that I'd like to have available via a consistent interface, include firewire and usb cameras (aux ADC's and DAC's are common for controlling pan tilt heads etc). Some of these could be implemented in userspace (and quite possibly should be,) but others would require driver changes that will effectively equal those of adding direct support for the subsystem described in these patches. * Spidev and i2cdev are fairly restricted interfaces which I have used extensively for initial investigation of sensors. The key thing here is that almost no devices use purely these interfaces. They include interrupt lines etc requiring relatively complex handlers. Thus any driver would probably require at least some kernel space element per chip anyway. Also worth noting that this tends to be the most complex and hence probably error prone part of these drivers. The spidev documentation talks about the limitations of the driver. An example of the problems that would be encountered with the current i2c-dev implementation within a full driver would be a control register read on a VTI SCA3000 (i2c) accelerometer. This would require an initial 3 byte write followed by a 1 byte read. In kernel space this whole thing can be set up in a dma capable buffer and done in one go with copies out to userspace only needed if the value is meant to be read by the user. * Need to provide kernel space interfaces. This actually fulls under the RFC question of what the scope of this subsystem should be. For example, things like battery chargers, free fall detectors etc frequently use generic components of the types that IIO will include. The systems that use these sometimes require kernel level access which a userspace driver clearly cannot supply. * Performance: Thinks like time stamping of data ready signals needs to be as near as possible to the source interrupt. As for the complex question of which is optimal for the ring buffering functionality, this would need thorough optimization of both approaches before it could be addressed. I'm not aware of any similar comparisons but would be grateful if anyone could direct me to any they know of. It is also worth noting here that many applications that will use the ring buffered interface will never actually read the contents of the buffer as they are interested in only restricted regions of data (based on some external trigger). In conclusion, I'd be interested in the long run in the possibility of moving all the above functionality into userspace but at the moment don't believe it to be the sensible option here. The alternative of would be to provide only those drivers that would benefit from a kernel space driver within this subsystem. This would lose the advantages to be gained from a consi
