linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Buffer size for iio_push_to_buffers_with_timestamp()
@ 2019-05-09 10:54 Gaëtan Carlier
  2019-05-11  8:48 ` Jonathan Cameron
  0 siblings, 1 reply; 4+ messages in thread
From: Gaëtan Carlier @ 2019-05-09 10:54 UTC (permalink / raw)
  To: linux-iio

Dear,

I have a question about the function iio_push_to_buffers_with_timestamp().

How kernel knows the size of the buffer ? Should the buffer always be 128 bits (with last 64 bits for timestamp) ?

Best regards,
Gaëtan.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Buffer size for iio_push_to_buffers_with_timestamp()
  2019-05-09 10:54 Buffer size for iio_push_to_buffers_with_timestamp() Gaëtan Carlier
@ 2019-05-11  8:48 ` Jonathan Cameron
  2019-05-12 13:53   ` Gaëtan Carlier
  0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Cameron @ 2019-05-11  8:48 UTC (permalink / raw)
  To: Gaëtan Carlier; +Cc: linux-iio

On Thu, 9 May 2019 12:54:34 +0200
Gaëtan Carlier <gcembed@gmail.com> wrote:

> Dear,
> 
> I have a question about the function iio_push_to_buffers_with_timestamp().
> 
> How kernel knows the size of the buffer ? Should the buffer always be 128 bits (with last 64 bits for timestamp) ?
Hi Gaëtan,

All fields in IIO buffers are 'naturally' aligned and must be power of 2 size
(8, 16, 32, 64)

This function is a bit 'odd' in that it needs a buffer that has space to insert
the 64 bit aligned, 64 bit timestamp.

So if your devices other channels fit in 64 bits then your conclusion is
correct.  If you have more channels then it may well be that the buffer
is already greater than 64 bits long before leaving space for the timestamp
and hence your buffer may need to be 192, 256 etc..

Hope that answers your question,

Jonathan

> 
> Best regards,
> Gaëtan.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Buffer size for iio_push_to_buffers_with_timestamp()
  2019-05-11  8:48 ` Jonathan Cameron
@ 2019-05-12 13:53   ` Gaëtan Carlier
  2019-05-18  8:54     ` Jonathan Cameron
  0 siblings, 1 reply; 4+ messages in thread
From: Gaëtan Carlier @ 2019-05-12 13:53 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: linux-iio

Hi Jonathan,

On 5/11/19 10:48 AM, Jonathan Cameron wrote:
> On Thu, 9 May 2019 12:54:34 +0200
> Gaëtan Carlier <gcembed@gmail.com> wrote:
> 
>> Dear,
>>
>> I have a question about the function iio_push_to_buffers_with_timestamp().
>>
>> How kernel knows the size of the buffer ? Should the buffer always be 128 bits (with last 64 bits for timestamp) ?
> Hi Gaëtan,
> 
> All fields in IIO buffers are 'naturally' aligned and must be power of 2 size
> (8, 16, 32, 64)
> 
> This function is a bit 'odd' in that it needs a buffer that has space to insert
> the 64 bit aligned, 64 bit timestamp.
> 
> So if your devices other channels fit in 64 bits then your conclusion is
> correct.  If you have more channels then it may well be that the buffer
> is already greater than 64 bits long before leaving space for the timestamp
> and hence your buffer may need to be 192, 256 etc..
> 
Thank you for your reply.

> Hope that answers your question,
So, I still have a question. How IIO functions knows how many space is available because it handles "void *". Is the size of allocated buffer stored somewhere ?

> 
> Jonathan
> 
>>
>> Best regards,
>> Gaëtan.
> 

Best regards,
Gaëtan.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Buffer size for iio_push_to_buffers_with_timestamp()
  2019-05-12 13:53   ` Gaëtan Carlier
@ 2019-05-18  8:54     ` Jonathan Cameron
  0 siblings, 0 replies; 4+ messages in thread
From: Jonathan Cameron @ 2019-05-18  8:54 UTC (permalink / raw)
  To: Gaëtan Carlier; +Cc: linux-iio

On Sun, 12 May 2019 15:53:44 +0200
Gaëtan Carlier <gcembed@gmail.com> wrote:

> Hi Jonathan,
> 
> On 5/11/19 10:48 AM, Jonathan Cameron wrote:
> > On Thu, 9 May 2019 12:54:34 +0200
> > Gaëtan Carlier <gcembed@gmail.com> wrote:
> >   
> >> Dear,
> >>
> >> I have a question about the function iio_push_to_buffers_with_timestamp().
> >>
> >> How kernel knows the size of the buffer ? Should the buffer always be 128 bits (with last 64 bits for timestamp) ?  
> > Hi Gaëtan,
> > 
> > All fields in IIO buffers are 'naturally' aligned and must be power of 2 size
> > (8, 16, 32, 64)
> > 
> > This function is a bit 'odd' in that it needs a buffer that has space to insert
> > the 64 bit aligned, 64 bit timestamp.
> > 
> > So if your devices other channels fit in 64 bits then your conclusion is
> > correct.  If you have more channels then it may well be that the buffer
> > is already greater than 64 bits long before leaving space for the timestamp
> > and hence your buffer may need to be 192, 256 etc..
> >   
> Thank you for your reply.
> 
> > Hope that answers your question,  
> So, I still have a question. How IIO functions knows how many space is available because it handles "void *".
> Is the size of allocated buffer stored somewhere ?
There is a cached value stored internally because the kfifo has to be
reinitialized to handle the correct sized buffer (amongst other
things)  This is computed from the descriptions of the enabled channels.

See iio_compute_scan_bytes in drivers/iio/industrialio-buffer.c

Note a driver should always be able to work out it's own answer to
that question. There are often more efficient ways of doing it
in a driver as it knows that all channels are the same size for
example.

Thanks,

Jonathan


> 
> > 
> > Jonathan
> >   
> >>
> >> Best regards,
> >> Gaëtan.  
> >   
> 
> Best regards,
> Gaëtan.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-05-18  8:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-09 10:54 Buffer size for iio_push_to_buffers_with_timestamp() Gaëtan Carlier
2019-05-11  8:48 ` Jonathan Cameron
2019-05-12 13:53   ` Gaëtan Carlier
2019-05-18  8:54     ` Jonathan Cameron

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).