... >>>>>> >>>>> 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 ;) -- 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
