On 06/02/10 09:01, Barry Song wrote:
> On Mon, Feb 22, 2010 at 7:16 PM, Jonathan Cameron <jic23@xxxxxxxxx> wrote:
>> Hi All,
>>
>> Just for reference as I'll be doing a proper announcement later.
>> We now have linux-iio@xxxxxxxxxxxxxxx as a mailing list for the project.
>> Unless others have tracked it down it currently only has me as a member
>> though and I'm waiting for confirmation from marc.info of an archive.
>>
>>> Hi Jonathan,
>>> Now users depend on iio ring events(IIO_EVENT_CODE_RING_50/75/100_FULL)
>>> to read data:
>>> read_size = fread(&dat, 1, sizeof(struct
>>> iio_event_data),
>>> fp_ev);
>>> switch (dat.id) {
>>> case IIO_EVENT_CODE_RING_100_FULL:
>>> toread = RingLength;
>>> break;
>>> case IIO_EVENT_CODE_RING_75_FULL:
>>> toread = RingLength*3/4;
>>> break;
>>> case IIO_EVENT_CODE_RING_50_FULL:
>>> toread = RingLength/2;
>>> break;
>>> default:
>>> printf("Unexpecteded event code\n");
>>> continue;
>>> }
>>> read_size = read(fp,
>>> data,
>>> toread*size_from_scanmode(NumVals,
>>> scan_ts));
>>> if (read_size == -EAGAIN) {
>>> printf("nothing available \n");
>>> continue;
>>> }
>>> And iio ring access node doesn't support blocking io too. It seems we
>>> lost to let users read data once ring is not empty. And some users maybe
>>> not care about iio ring events at all, but just want to read data like a
>>> input or audio driver. So how about adding the following support in iio
>>> ring:
>>> 1. add NOT EMPTY event in IIO event nodes
>> Not keen. It might lead to a storm of events (at least it might in a
>> cleverer ring buffer implementation or during a blocking read). Actually
>> in this particular case it probably wouldn't do any harm.
>>> 2. add blocking io support in read function of IIO access nodes
>> That I agree would be a good idea. If we support poll/select on the buffer access
>> chrdev then we will get the same effect per having a not empty event and cleaner
>> semantics for anyone not interested in the other events. Not to mention I expect
>> we will soon have alternative ring buffer implementations that don't supply any
>> events at all and hence don't event have the relevant chrdev.
>>
>> As things are, you can quite happily read whenever you like. Now you mention it,
>> that example code is somewhat missleading! The issue with
>> this ring buffer implementation is the handling of a true blocking read is complex
>> as at any given time you aren't guaranteed to get what you asked for even if it was
>> there when you started the read. It should be possible to work around that though.
>>
>> It's possible this functionality might be better added to an alternative ring buffer
>> implementation. Be vary wary of that ring implementation in general! I am and I wrote it.
>>> If you agree with that, I can begin to add these and send you a patch.
>>> And a problem I don't know is what you and other people have changed to
>>> Greg's staging tree, and I am not sure what tree the patch should be
>>> againest.
>> Nothing has changed in this region of the code. In fact I think all that
>> has gone into Greg's tree is a clean up patch form Mark Brown making a few
>> functions static. Right now I'm still getting the max1363 driver into
>> a state where it will be possible to do the ABI changes.
>>>
>>> For long term plan, is it possible for ring common level to handle more
>>> common work to avoid code repeating in different drivers?
>> I'm certainly happy for that to be the case if it becomes apparent which functionality
>> is shared. I haven't seen any substantial cases as yet, but then I may well be missing
>> things so feel free to submit suggestions (or as ever the better option of patches).
>
> Now we have many drivers using SW ring with same
> preenable(),postenable(),predisable(),
> initialize_ring(),uninitialize_ring(),poll_func(),probe_trigger(),
> remove_trigger(). Can we move them to IIO common layer as a base class
> methods. And the derived class can overload them if they have special
> implement? Most devices just use the common layer and don't need to
> copy codes.
Sounds sensible. Please propose a patch.
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
