Re: Requirement for at91-sama5d2_adc timestamp buffer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 30, 2020 at 2:29 PM <Eugen.Hristev@xxxxxxxxxxxxx> wrote:
>
> Hello Jonathan,
>
> I found an issue with at91-sama5d2_adc driver, namely, when using DMA
> and timestamp in the same time, the hardware provides the sample in the
> fashion (2 bytes per channel) * (number of channels) - as copied by the
> DMA master to memory.
> I compute a software timestamp , and then push to buffers with timestamp.
> However your push code will try to write this timestamp inside my buffer
> ! and overwrite my samples... I have multiple samples in the buffer
> (watermark number) and there is no space between them because the
> hardware copies the conversion data directly in this buffer.
>
> Do you have any suggestion on how to solve this, except 1) giving up the
> timestamp in this mode or 2) copy to another buffer with more space for
> timestamp storage ?

I'm assuming the issue is here:
                iio_push_to_buffers_with_timestamp(indio_dev,
                                (st->dma_st.rx_buf + st->dma_st.buf_idx),
                                (st->dma_st.dma_ts + interval * sample_index));

Can the DMA be configured to add some padding in-between the samples?
It looks like the way this is currently working, timestamps cannot
work with the DMA buffers and multiple consecutive samples.
But, it may be that this case is a bit unrealistic; or shouldn't be supported.
DMA is used to provide really-fast transfers; computing timestamps in
SW for each sample would slow things down to the point where the
transfers aren't fast anymore.

What would [possibly] be an alternative, is to do a
"iio_push_multiple_samples_to_buffers_with_timestamp(indio_dev, buffer
for 1 sample-set, n_samples, )".
That would basically mean, the DMA gets 10, 100, 1000 samples, and
adds a timestamp at the end.
Now, the only thing that I don't know here: is how userspace would be
able to determine the number of samples until the next timestamp.
I guess some mechanism could be extended inside IIO to accommodate for
this; N_samples_till_timestamp counter, with a default value of 1.
Not sure if it makes sense though.

>
> Thanks,
> Eugen



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux