Hi Jonathan, Am 27.08.2010 16:24, schrieb Jonathan Cameron:
As things currently stand these are in iio:device[n]/scan_elements. I guess we could move them into iio:device[n]/buffer0 It is a bit of a pain in code as the buffer directory is completely managed by the buffer implementation rather than the driver. Still I guess this could be passed to the buffer initialization code. Things are a bit tricky as there are other attributes caused by the buffer it self. It cleans up the abi at the cost of further messing up the separation between buffer implementation and device driver and some complexity in driver. It would be easier to move the scan_elements directory into the buffer directory? Perhaps that is the better option? What do others think on this?I have no problem with moving the whole directory.Cool. I'll have a look to see how clean we can make the move. It is going to break a lot of drivers in the Analog devices tree so it might be worth delaying it for now (perhaps updating the abi and saying the old location is deprecated).
Indeed I did that for the last few hours. A patch is coming on Monday.
- Endianess of the buffers: * Device specific? Then we need a sysfs file to publish this info. * CPU native byte order?It is currently cpu native for all software ring buffers. Agreed this may change and hardware buffers may do either. So you are quite right, we need an attribute for this. So I guess we support 3 options, cpu native, big endian, little endian. So what shall we call it? byte_order - [big little native] Mostly read only, though sooner or later I expect we will get some device that allows this to be controlled.Do we really need native? I think the driver can figure out what the native order is, and just give that one (even at compile time).Good point.Another possibility is to let the driver always convert to native.Bad idea. In a hw ring buffer case that adds a lot of overhead for straight logging applications where we just want to store what the data is rather than do anything with it live. At least that's what most userspace software want's to have. I recently sent a patch for sca3000 to the linux-iio list. Strange, those never made it to my inbox. I'm guessing my iio subscription must have borked. I'll get them from the archive. On those patches, I'm happy to ack the first (not sure when that bug snuck in and I'm not in a possition to test the fix today). As per this discussion I'd rather avoid the data munging of the second. That's a job for userspace. Obviously we'll be needing the stuff you specify below for that though.
OK, will be my next task.
Probably not using the current ring buffer. As you say a big issue is how to describe a packed storage particularly if not all of it is packed. (so say 2 x 11 bit readings in 3 bytes - for say a 4 channel device, this is a better bet than packing it tightly into 44 bits.) So far we haven't had a hardware ring device giving us packed data, but I'm sure one will turn up and force this element sometime in the future. I think we leave this until a user comes along then pin it down then. I agree it is definitely something we need to consider, just not now! Still if you want to lay out some guidance for discussion feel free.OK, no packed buffers for now, but we should implement variable sample sizes for standard types. Indeed we already have this for the timestamp, which is always 64 bit.Agreed. These ought to be in there and will be neededTo be compatible with future extensions we could have: |- /sys/bus/iio/ii0/buffer0/scan_elements/ |- accel_x:en (0 or 1) |- accel_x:type (i.e. s14/16, see *) |- accel_x:index* s14/16 means signed 14 bits, stored in 16 bits, right aligned. If it's left aligned we can just modify the scale attribute and give the 16 bit interpretation in <channel>:raw.That is quite a neat way of doing it though I'm not sure 'type' is the ideal name. My immediate thought is that type would be 'acceleration'! We definitely want this on list. We'd also want to drop the precision attribute as that will just confuse things.
I'm open for any other name.
I don't like the index prefix any more, even I had proposed this once. This is because for devices with more than 10 channels (adis16400) we have to get a leading 0 in the name to maintain alphabetical sorting, which is nearly impossible with the current macros.Does alphabetical sorting really matter? + Doesn't putting 01 etc in the macro give the right name? I thought it was stringified in the first step (could be wrong, that macro stuff always gives me a headache). We definitely need the prefix or equivalent so this is worth clearing up.
If it doesn't sort alphabetically, there no point in having a prefix. It was thought as a helper for the human user. Currently the number is a preprocessor definition and used both as prefix and as number. If there's a 0 in front, it will be interpreted as octal number.
Regards, -- Dipl.-Inf. Manuel Stahl Fraunhofer-Institut für Integrierte Schaltungen IIS - Leistungsoptimierte Systeme - Nordostpark 93 Telefon +49 (0)911/58061-6419 90411 Nürnberg Fax +49 (0)911/58061-6398 http://www.iis.fraunhofer.de manuel.stahl@xxxxxxxxxxxxxxxxx
begin:vcard fn:Manuel Stahl n:Stahl;Manuel email;internet:manuel.stahl@xxxxxxxxxxxxxxxxx tel;work:+49 911 58061-6419 x-mozilla-html:FALSE version:2.1 end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
