Re: read /dev/iio:device0 return -1 (Invalid argument)

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

 



On 12/12/15 08:36, Julio Cruz wrote:
> Hi,
> 
> I get an error trying to read /dev/iio:device0 in a custom application
> (C/C++), however in a terminal the command "cat /dev/iio_device0"
> return data.
> 
> Below the procedure:
> 
> - enable channels
> - setup trigger
> - setup buffer lenght
> - enable buffer (the SPI interrupt is setup properly and all the
> trigger handler are done)
> - read /dev/iio_device0
> 
> It's a SPI device acquiring 27 bytes @ 1KHz.
Reading this again after point 4 below this makes me ask the question
what are you pushing into the buffer? 27 bytes seems unlikely given
the alignment requirements.

> 
> Results:
> 
> 1. Custom application (based on generic_buffer.c): function 'read'
> return -1 and strerror(errno) return "Invalid argument"
> 2. iio_readdev (libiio): show the message "Unable to refill buffer:
> Input/output error"
> 3. In terminal, the command "cat /dev/iio_device0" show values (no
> readable) while the buffer is enable.
> 
> Any suggestion?
> 
> Thanks for your help!
Sounds like you are ultimately getting that error from a call to
 iio_buffer_read_first_n_outer
so what can return -EINVAL (which is -1)?

1) Buffer not being allocated (seems unlikely - that's really just to
pick up on bugs in side the driver)
2) read_first_n from the buffer not supplied - again not likely.
3) wait_event_interruptible returns it - unlikely.
4) read_first_n which comes from the buffer implementation is returning -EINVAL
This last one seems most likely.

So I am guessing you are using the kfifo buffer (most common option).
Reasons this can return -EINVAL are
1) kfifo not initialized (unlikely)
2) Read length is less than the buffer element size (which is the full scan storage
size)
3) an error from kfifo_to_user (unlikely)

So I'm guessing you are reading too small an amount of data. (tricky to chase
down without adding further printk's etc to the relevant bits of kernel code)
If I've 'guessed' right, interesting question is how this came about.
How many bytes is it trying to read?

Note that IIO has strict alignment requirements - any element must be aligned
to it's own size and this will in some case add lots of padding.  The full buffer
element will be a multiple of the largest element in the scan.  If you have a timestamp
for example at 64bits the whole buffer element will be a multiple of 8bytes.

Jonathan
> --
> 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
> 

--
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



[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