On Tue, May 11, 2010 at 7:30 PM, Jonathan Cameron <jic23@xxxxxxxxx> wrote: > > On 05/11/10 08:59, Barry Song wrote: > > Jonathan, > > adis16260 in drivers/staging/iio/gyro/ has been ready too. > > Do you have time to take a look at the datasheet of adis16220? I think > > it is much different. The chip has no register to show the current > > sample value. It only has a capture buffer mode. For every capture(by > > manual or by period at least 1 second), the ADIS16220 produces and > > stores 1024 > > samples of acceleration and analog input channel data into the capture > > buffers. It has no a fixed frequency to sample, by depends on user > > commands or timer to trigger a capture. > > I've been waiting for a device like this to be supported :) > > > I think current iio doesn't support it at all: > > 1. sysfs node is useless to show current value > Indeed so don't supply one. All the sysfs interfaces are optional and should > only be supplied where they make sense. > > 2. it doesn't sample periodically, so ring is useless too. > Agreed that the ring buffer you have been using for the others is > inappropriate. However, what you have below looks very like a > hardware buffer (see the accel/sca3000_ring.c for an example). > > Its work flow is: > > capture -> 1024 data -> capture -> 1024 data -> capture -> 1024 data .... > > I want to add a binary sysfs node for capture buffer. > No. This really isn't a single value so it won't be accepted for mainline. binary sysfs node is not a single value but a document which can hold much data. some devices like i2c eeprom are using bin_attribute to support read and write a big memory. > Every time, users > > begin a capture, after finishing, read 1024 data from the binary node. > > > > Do you have any idea? > Yes. I'd set the whole thing up as a hardware buffer. As an aside, we > really need to get the word 'ring' out of the code at some point given > quite a few implementations aren't going to be rings. i don't think it is a hardware ring buffer. every-time, data number is fixed 1024 for a capture event. Without periodic input, a binary node should be enough for this. > > From the datasheet I see there are a couple of different ways to trigger > capture. I would be inclined to handle the manual mode via a trigger. > I think a general userspace manual trigger would be helpful anyway for > testing other devices if nothing else. Probably just a sysfs attribute > called capture_now that otherwise looks much like the gpio trigger. > > The timer option is more or less the equivalent of a conventional fixed > frequency capture (be it with a lot of data per capture!). One could > supply a trigger to indicate this has finished. Probably better to have > the event in question come from the buffer event chrdev (see below). > > The last option of doing it based on an event is more interesting. > The options that come to mind are: > > * A seperate trigger - You would need a way for other devices to know the > trigger has fired. This would pretty much require tying the alarm in question > to one of the gpio pins so as to pass the notification on. Perhaps this only > happens if another device attaches to the trigger? (bit fiddly to code). > > * Do it internally as control attributes of a new hardware buffer. > If you are also supporting general alarm events the logic would get a little > complex as obviously these could be shared (event can trigger a buffer fill > as well as causing an external gpio interrupt). > > I would prefer the first option, but the second is fine for now if it is > easier to code up. The first allows us to say chain on a gyro to get > additional info triggered off trigger events from adis16220. Clearly > there are a few complexities to be considered. For one thing the exact > nature of the trigger consumer function would be different from the userspace > trigger (when it would cause a capture) to the event based triggers > (where the capture would already have happened). This is actually a case > that needs better handling in some of the current drivers. In theory > with the lis3l02dq for example, one can trigger another device off it's > datardy signal without actually triggering the lis3l02dq itself. This > would result in no read of data and the datardy signal would not clear. > Obviously this would be a pretty strange thing to do, but the interface > does allow it and so it ought to be nicely handled. Currently it is not! > That one has been at the bottom of the todo list for a long time. > > The new buffer would have an event chrdev from which a new type of event > can be read (not sure on naming, something like BUFFER_CAPTURE_EVENT_FINISHED) > It would also have an access chrdev as per the software ring you have > been using so far. This access chrdev will read directly (via spi) from the > buffer on the device. A while back there was some discussion about whether > devices like these (with hardware buffering) should always feed into an > intermediate software buffer. Personally I don't think they need to and > if we decide otherwise this can always be added at a later date. > > Obviously there would be a number of new abi elements introduced that might > well generalize over a range of devices, so if you go this way please propose > them formally on the list (and possibly also lkml) for discussion. > > Thanks, > > Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
