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