[spi-devel-general] Accelerometer, Gyros and ADC's etc within the kernel.
This email is basically a request for opinions on how and where such sensors should be integrated into the kernel. To set the scene... Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to fit with in an particular subsystem of the kernel. A previous discussion on lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions of such non hardware monitoring sensors. The obvious possibilities are: * To place the various drivers within the spi / i2c etc subsystems as relevant. * To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon) * To create a new subsystem, or perhaps merely sysfs class to contain these elements. Typical requirements within an application include simply polling for current readings, and using device triggered interrupts to grab data continuously to a ring buffer, for collection by suitable userspace code. Obviously it would be desirable to standardize sysfs controls for various calibration parameters as much as possible across the various devices. Any other suggestions welcome! To illustrate the sort of devices here are a few I have drivers written for or will shortly be writing (some submitted to hwmon and spi mailing lists, some not finished as of yet) ST Micro LIS3L02DQ 3D accelerometer. SPI device, no buffering, interrupt pin raised high on new data being available. Currently the driver assumes, if interrupts are enabled, that this is connected to a specified gpio. (http://www.st.com/stonline/books/pdf/docs/10175.pdf) VTI SCA3000 E05 3D accelerometer equiped with substantial ring buffer. SPI device. Can operate either in buffered or direct mode. In buffered mode, interrupts can be used to indicate when the ring buffer is 3/4 full triggering a download to a larger ring buffer in the kernel if necessary. (http://www.vti.fi/en/products-solutions/products/accelerometers/sca3000-accelerometers/) Analog Devices ADIS16350 combined 3D accelerometer and gyro unit. SPI device. (http://www.analog.com/en/prod/0,,764_801_ADIS16350%2C00.html) Maxim MAX1363, MAX1238 ADC's. I2C devices. Some SPI ADC's (www.analog.com for examples) Would be nice if practical to allow the framework to include RS232 devices such as those from www.xsens.com, www.isense.com and others. -- Jonathan Cameron - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] Accelerometer, Gyros and ADC's etc within the kernel.
Hi Jonathan, On Tue, 20 May 2008 11:04:01 +0100, Jonathan Cameron wrote: This email is basically a request for opinions on how and where such sensors should be integrated into the kernel. To set the scene... Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to fit with in an particular subsystem of the kernel. A previous discussion on lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions of such non hardware monitoring sensors. The obvious possibilities are: * To place the various drivers within the spi / i2c etc subsystems as relevant. Bad idea. Grouping drivers by connectivity is almost always the wrong thing to do, as it means that different persons will maintain them and they have all chances to diverge. You really want to group drivers by functionality. On top of that, I am busy enough maintaining the i2c core and bus drivers without having more i2c device drivers added to my plate. These days I am trying to _empty_ drivers/i2c/chips, if anything. * To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon) Probably not the wisest choice, if nothing else, because the hwmon maintainer is already overloaded. And I don't think that these devices have much in common with the traditional hardware monitoring components anyway. I'm not sure what straight ADC driver you are referring to, but anything which measures a voltage and exports the reading to user-space is, well, a voltage sensor, and thus fix within hwmon. If the same chip is used for a higher-level, dedicated function then we would probably have a separate driver for it, outside of hwmon. * To create a new subsystem, or perhaps merely sysfs class to contain these elements. Would be OK. Or: * Place these within the input subsystem. You might want to discuss this with the input subsystem maintainer Dmitry Torokhov (Cc'd). The Wii remote is essentially a joystick, and joysticks belong to the input subsystem. Typical requirements within an application include simply polling for current readings, and using device triggered interrupts to grab data continuously to a ring buffer, for collection by suitable userspace code. Obviously it would be desirable to standardize sysfs controls for various calibration parameters as much as possible across the various devices. Any other suggestions welcome! This all sounds quite different from our hwmon drivers. Our hwmon drivers read all the sensor values at once and cache the readings for a couple seconds, so you can't get an instant reading at any time, and they also don't support interrupts in general. -- Jean Delvare - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH 3/4] spi: Add OF binding support for SPI busses
On Tue, May 20, 2008 at 9:26 AM, Guennadi Liakhovetski [EMAIL PROTECTED] wrote: On Mon, 19 May 2008, Grant Likely wrote: I'm not so fond of this approach. cs-parent doesn't seem to make much sense to me. It might be better to have a cs-handler property on the SPI bus node instead of on the SPI slave nodes, but even then it leaves a number of questions about what it really means. In some cases it would be overkill. For example, if the SPI node simply had multiple GPIO lines then an extra cs-parent node wouldn't be needed at all. Right, it is optional. Then there are the complex arrangements. When setting CS requires inserting a special 'set cs' SPI message at the right time. Or worse; when setting CS requires /modifying/ the sent SPI message. Hm, are there actually such SPI _controllers_ that use SPI data to toggle chipselects? I.e., you would have to send your SPI client data (for the RTC or whatever) plus some extra bytes or with some modifications, and this extra information would then be intercepted by the SPI _controller_ itself and only client data would be sent out? Yes! There really are!!! One case I've been told of is an SPI bridge that uses the first byte of the transfer to obtain the chip select. Isn't what you're describing really a case of an SPI bridge, as you also call it below? In which case, I think, it might make sense to cleanly differentiate these two cases: 1. SPI chipselect. Either controlled by an external (typically a GPIO) signal or by the controller itself, in the latter case the controller has to be configured with the required address 2. SPI bridge. I don't know such configurations, so, I can only guess: the SPI controller has a single SPI client, which acts like a bridge. It receives data from the primary host, and in this data the target client data and its address are encoded. Yes, this is probably appropriate. Now, I can also imagine case 2 where the bridge is actually a part of the host controller... Even though this doesn't make any sense to me. Hmmm, yeah, I suppose it is possible; but if it is internal to the bus controller then it can also be handled internally by the bus controller driver and probably won't need to be reflected in the device tree layout. Essentially, the binding would need to describe the ability to completely intercept and rewrite all SPI messages going through the CS scheme. It also needs to describe layouts which require SPI transfers in a particular order. For example, if you're doing 2 SPI messages (M1 and M2) to 2 different SPI devices (S1 and S2), and the CS lines are on a GPIO expander which is a third SPI device (S3). In which case 5 or 6 SPI messages need to be transmitted: ctrl msg - S3// To set the CS to S1 M1 - S1 ctrl msg - S3// To clear the CS to S1 ctrl msg - S3// To set the CS to S2 M2 - S2 ctrl msg - S3// To clear the CS to S2 An important subtlety to note here is that the GPIO device (S3) cannot simply enqueue the control message to the SPI device when it is time to send M1 or M2. Normal enqueuing would add the messages to the end of the queue; too late to actually activate the relevant CS line. Granted, the is mostly a driver issue; not a device tree issue; but it has some impact on the layout. It could be handled with the spi_bridge construct, but S1 and S2 aren't really children of S3. On the other hand; the spi_bridge is really more of a board level construct. The spi_bridge could be considered the board wireup and S1, S2 and S3 are all children of the spi_bridge. The spi_bridge would have to be knowledgeable enough to handle control messages to S3 in a special order. I'm not saying it's not possible to do, but I am saying that I'd like to have a better feel for all the use cases before it is defined. I'm not convinced that adding a cs-parent phandle will do that appropriately. That being said, my gut feel is that the solution will be to support spi-bridge nodes that handle the complex CS configuration settings; the spi-bridge would be a child of the spi-master and the parent of the spi devices; and simple CS settings being handled with regular old GPIO bindings. (Much like the last suggestion you make; except that I think that it *does* looks elegant.) :-) Ok, elegance apart:-) You can use the SPI-bridge construct to also describe simple SPI-chipselect configurations. But is it really a good idea? Wouldn't it be better to handle these two cases separately? Using bridge to describe CS's seems also confusing - imagine someone implementing a new DTS, having to describe a bridge not having one doesn't seem very intuitive:-) ... and it must be said that I got rather lazy in my example below. I really covered both layouts (simple GPIO and an SPI bridge in the same example without documenting it sufficiently. I'll hash out my thoughts some more and post a series of better examples this afternoon. example; here's an SPI bus that has
Re: [spi-devel-general] Accelerometer, Gyros and ADC's etc within the kernel.
On Tue, May 20, 2008 at 11:04:01AM +0100, Jonathan Cameron wrote: This email is basically a request for opinions on how and where such sensors should be integrated into the kernel. To set the scene... Increasing numbers of embedded devices are being supplied attached MEMS devices (www.xbow.com imote2 etc). Along with more traditional sensors such as ADC's not being used for hardware monitoring, these do not really seem to fit with in an particular subsystem of the kernel. A previous discussion on lkml in 2006 considered the accelerometers to be found within some laptop hard drives, but I haven't been able to track down any more general discussions of such non hardware monitoring sensors. The obvious possibilities are: * To place the various drivers within the spi / i2c etc subsystems as relevant. * To place within the hwmon subsystem as this is probably closest. (there is already at least one straight ADC driver in hwmon) * To create a new subsystem, or perhaps merely sysfs class to contain these elements. Typical requirements within an application include simply polling for current readings, and using device triggered interrupts to grab data continuously to a ring buffer, for collection by suitable userspace code. Obviously it would be desirable to standardize sysfs controls for various calibration parameters as much as possible across the various devices. Any other suggestions welcome! To illustrate the sort of devices here are a few I have drivers written for or will shortly be writing (some submitted to hwmon and spi mailing lists, some not finished as of yet) ST Micro LIS3L02DQ 3D accelerometer. SPI device, no buffering, interrupt pin raised high on new data being available. Currently the driver assumes, if interrupts are enabled, that this is connected to a specified gpio. (http://www.st.com/stonline/books/pdf/docs/10175.pdf) FWIW: I have this device talking to a PIC-18 and pushing the results over the serial port. WRT linux support, I can't think of a generalized way to create a driver that would be able to be used with this device in Linux. You need to know witch IRQ line the DR line is connected too, and if you are bit-banging the SPI data off the thing, then you need to know which GPIO's of the host CPU you'll be using. If you have SPI hardware then you need to know where to pull the data from. The problem doesn't seem to generalize well. Also, If you are playing with accelerometer data, you likely need some real time support or at lest a reliable time stamping of the data to do anything interesting. Another problem area is around SPI itself. There are variations of device implementations around chip select polarity, clock biasing (rising,falling, or midpoint) sampling from one SPI part to the next. VTI SCA3000 E05 3D accelerometer equiped with substantial ring buffer. SPI device. Can operate either in buffered or direct mode. In buffered mode, interrupts can be used to indicate when the ring buffer is 3/4 full triggering a download to a larger ring buffer in the kernel if necessary. (http://www.vti.fi/en/products-solutions/products/accelerometers/sca3000-accelerometers/) ring buffered data can make RT applications harder... Analog Devices ADIS16350 combined 3D accelerometer and gyro unit. SPI device. (http://www.analog.com/en/prod/0,,764_801_ADIS16350%2C00.html) Maxim MAX1363, MAX1238 ADC's. I2C devices. Some SPI ADC's (www.analog.com for examples) Would be nice if practical to allow the framework to include RS232 devices such as those from www.xsens.com, www.isense.com and others. I'm not sure what you are asking for, you started off with SPI driver for interfacing a handful of accelerometer devices. Now your talking about the serial port. Besides the consumer of accelerometer data is user space applications (mine attempt to be somewhat RT applications) --mgross - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
