> On 03.11.2017 08:17, Jonathan Cameron wrote: > > > I assume we are talking a hw fifo? I'm going to guess with a watershed > > interrupt... > > What exactly does "watershed interrupt" mean in this context ? An interrupt that fires once you have N samples in the buffer rather than just one. > > Per ADC we have 2 buffers, while one is filled by adc, while the other > is read out by the the cpu. (unfortunately they're not visible as a > memory block, but only a fifo head register - hopefully we can change > that, so i can just use memcpy() or dma engine). When one buffer is > full, the corresponding interrupt is trigged and adc switches to > filling the other one. OK, to software that looks like a fixed watershed. > > > Triggers are used when you have a single interrupt for each sample > > pass of a given ADC. (a so called scan - of data captured at the same > > time - or often based on an internal shared sequencer). > > Is a sample pass limited to one sample, or can it be a whole block > of samples ? With a few fiddly exceptions it is a maximum of one reading per channel (depending on what channels are enabled). > > > So typically when you have a flow involving a hardware buffer you skip > > the trigger and have the interrupt controller push data directly to the > > buffers from the interrupt handler thread. > > That was my idea. Is there already some driver which does exactly that ? > (with blocks of samples instead of just a single one) Yes - ti-am335x adc driver for example. Various other drivers offer this as an optional mode when a hw fifo is enabled. > > > If you have 3 different interrupts and the ADCs have separate buffers > > then you can't guarantee to do reads from all on a single interrupt? > > Theoretically, the adcs should be synchronous, but the buffers and > interrupts are separated (the original requirements demanded separate > sampling rates defined potentially separate sampling rates, but in > the meantime changed to same rate for all). > > > In that case, as far as IIO is concerned you have 3 separate ADC > > systems which will need to each be a separate IIO device. > > Why not 3 channels w/ separate interrupts ? Because there is no meta data in the channel so if you were to get a case where they got out of sync, there would be no means of identifying that. The data flow is very lightweight - this comes at the penalty of having to have fixed/restricted options on interleaving of data. Samples need to also be say A1,B1,A2,B2 etc if on a single buffer. > > Do multiple channels of one device always share the same sampling rate > and sampling points (like stereo channels on an audio device) ? Yes + interleaved as described above. > > > There is also infrastructure to match the fifo watershed with the > > software one so that you only read from the hardware when you want > > to read it from userspace. > > How does that work ? Take a look at the ti driver. I think it does this. In your case it sounds like you have a fixed hardware watershed anyway so this isn't going to help you. Jonathan > > --mtx > > -- > Enrico Weigelt, metux IT consult > Free software and Linux embedded engineering > info@xxxxxxxxx -- +49-151-27565287 > -- > 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 ��.n��������+%������w��{.n�����{��(��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
