Re: Updating the todo list.

[Jonathan Cameron <jic23@cam.ac.uk>]

...
>>>>>>
>>>>> Yes - that's a good thing todo.
>>>>> In addition we should also make sure that buffers may function in both directions.
>>>> Hmm.. The actual implementation would at least initially be completely separate. I think
>>>> the abi would certainly allow this as is though. Whilst I agree this would be useful, we
>>>> don't have an implementation and it seems non trivial. Last time we talked about it,
>>>> I got the impression quite a lot of bus level stuff had to be added before this
>>>> could actually be useful?
>>> If you think about making the SPI bus more deterministic, then I agree.
>>> However there may be various other use cases.
>>>
>>> 1)
>>> Most ADI precision DACs feature a LDAC (Load DAC) strobe. You could use a
>>> iio-trigger for example a HW timer or PWM with an output strobe, directly connected
>>> to the LDAC strobe, in the iio-trigger handler you could write the next value into the
>>> shadow/shift register of the DAC. This way you get no jitter on the update rate, the only
>>> timing constraint is that the new value is loaded before the next trigger occurs.
>> Hmm.. Interesting use for a trigger.  No reason why not though...
>>> 2)
>>> Think about data sink devices with build in buffers.
>> Those I agree are interesting, but do we have any?
> 
> Not today. But we're planning to create drivers that talk to
> peripheral blocks synthesized in HDL and running on FPGAs
> in combination with FPGA hard and soft-cores running Linux.
> These peripheral blocks will feature buffers/fifos  to bridge
> interrupt service latencies or to reduce the peripheral service frequency.
Sounds interesting.  Right now though I think we just need to sanity check that the abi
will work for this (with extensions, but no changes).  I think it will but could you
take a look and see if there is anything I've missed?
>>> 3)
>>> Don't think about Linux SPI or I2C bus drivers at all.
>> Fair enough.  They are my home territory, so I'll be following your lead on this stuff.
>>> So there can be lot's of cases where IIO user space write-able buffers are useful.
>> Agreed, though I'm not sure the have the same requirements as the read out buffers.  Looks
>> to me exactly the other way around.  Userspace writes lot occasionally and kernel pushes
>> individual (or hardware buffer does).  Nothing wrong with sharing userspace interfaces
>> (specification of contents of buffer etc), but my gut feeling is the implementation may
>> not share much at all.
> 
> A implementation based on kfifo should be sufficient, and is actually pretty straight forward.
Excellent.  I look forward to seeing a driver ;)