On 07/22/11 10:54, Jonathan Cameron wrote:
> Hi All,
>
> Given Michael has already run out of space in our 32 bit event code I suggest
> we bite the bullet and move over to a 64 bit one now. I doubt there is much
> userspace code in place so this shouldn't be 'too' painful.
>
> So to start the ball rolling, how about the following split.
> The final will probably still be a macro of doom. Bitfields get a bit
> confusing cross architectures. I 'think' the following should even
> be fine of arm oabi (IIRC that has 4 byte alignment for structures).
>
> The following avoids all the conditionals we currently have in the macro.
> It costs us space, but we have more of that. Note we'll need to add
> a NO_MOD modifier and add 1 to all the modifier codes. It should also
> allow us to use enums for everything.
>
> /**
> * iio_event - general purpose event to userspace.
> * @time: timestamp
> * @chan: index of non differential channel
> * @chan1: index of first end of differential channel
> * @chan2: index of second end of differential channel
> * @chan_type: an iio_chan_type (we currently have 15)
> * @modifier: currently we interleave several types of these (axial, light).
> * having this much space would allow us to relax that and lead to
> * simpler code.
> * @direction: currently only 3, but definitely want level versions as well.
> * @type: event type (currently thresh, mag, roc). Can see we will have more
> * of these.
Forgot to say, this also effects the size of the event_mask in iio_chan_spec.
Right now that allows for 8 types and 4 directions. It's going to be fiddly to
allow that to expand beyond 64 bits.
> */
>
> struct iio_event {
> int64_t time;
> union {
> unsigned chan:32;
> struct {
> unsigned chan1:16;
> unsigned chan2:16;
> };
> };
> unsigned chan_type:8;
> unsigned modifier:8;
> unsigned direction:8;
> unsigned type:8;
> };
>
> So the question is, is this rough and ready distribution of bits good
> enough, or do we need more channel types for example at the cost of some
> directions?
>
> I'll hack some patches based on this together shortly so we can see what
> other cleanups it allows.
>
> 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
>
--
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
