Am 23.09.2010 18:18, schrieb Jonathan Cameron:
On 09/23/10 14:09, Jonathan Cameron wrote:This proposal is based on an observation of Manuel's that we could construct all of our event codes in a much more logical fashion by breaking them up into a series of bit fields within the event code. So lets define this as a structure for the purposes of this discussion. The eventual implementation would probably be done with macros. I'm assuming it makes sense to have a single 32bit number as the event code. Sorry for the abuse of kernel doc. I have no idea how one actually documents unions or structures within structures. /** * iio_event_code - structure representing an event * @sensor_type: 256 codes for different classes of sensors * - accel, gyro, in, light etc. * @directedornot: Tells us whether the modifier is for a sensor * with axes or one where this doesn't make sense. * @modifier: identify which channel * @directed: modifier for sensor where an axis makes sense * @direction: 16 different directions, x, y, z + compound * versions x|y|z x|y x|z y|z x&y&z x&y x&z y&z * @number: allow up to 8 sensors in a given direction if * it is a sensor where direction makes sense. * @number: for sensor where axis doesn't make sense allow 128 channels * @type: thresh, mag, roc + specific things like free fall etc. * @direction: falling or rising or either. (so there are some spare bits here). **/ struct iio_event_code { unsigned sensor_type:8; union { unsigned directedornot:1; struct { unsigned direction:4; unsigned number:3; } directed; unsigned number:7; } modifer; unsigned type:8; unsigned direction:8; }; So would people be happy with this rough approach. + please comment on the exact layout and in particular point out classes of event that do not fit. The interpretation of everything after sensor_type for buffer events will probably have to be separately defined. It would complicate this too much. Given the resounding silence that followed my recent post asking for wider opinions on naming of such events (to lkml), I'll probably just get on with implementing the scheme we suggested there for naming the attributes etc.Given I had a little time this afternoon and I'm fairly sure we will end up with something similar to the above I started implementing it. One particular lesson came to mind. If we allow particular channels to have 'names' then we must also oblige them to have an associated number. We don't want to get into the game of having a huge list of label to event code conversions. So taking what we currently have in tree... in_supply -> in0_supply (and move in0 to in1) intensity_both -> intensity0_both intensity_ir -> intensity1_ir etc.
Guess we could also use the scan_element ordering as unique 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 -- 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
