IIO: Why cannot open two iio device node file descriptors simultaneously ?

IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Aniroop Mathur]

Dear Mr. Jonathan Cameron and IIO Community,
Greetings of the day !! :)

I am Aniroop Mathur working in Sensors kernel and HAL field for last two years
I have one question about IIO, for which i need your support.

I would like to open two file descriptors for IIO device node - /dev/iio:device0
int fd1 = open("/dev/iio:device0",O_RDONLY);
int fd2 = open("/dev/iio:device0",O_RDONLY);

But, only first open call succeeds.
The second open calls fails with error "Device or Resource busy".

In normal input device, we can open as many event node file
descriptors as we like.
int fd1 = open("/dev/input/event1");
int fd2 = open("/dev/input/event1");

Both calls succeeds for input subsystem case.

So, why restriction is present in IIO subsystem ?
Why two iio device nodes cannot be open together ?

Thanks a lot in advance !

Regards,
Aniroop Mathur

IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Aniroop Mathur]

Dear IIO Community,
Greetings !!

I am Aniroop Mathur working in Sensors kernel and HAL field.
I have one question about IIO, for which i need your support.

I would like to open two file descriptors for IIO device node - /dev/iio:device0
int fd1 = open("/dev/iio:device0",O_RDONLY);
int fd2 = open("/dev/iio:device0",O_RDONLY);

But, only first open call succeeds.
The second open calls fails with error "Device or Resource busy".

In normal input device, we can open as many event node file
descriptors as we like.
int fd1 = open("/dev/input/event1");
int fd2 = open("/dev/input/event1");

Both calls succeeds for input subsystem case.

So, why restriction is present in IIO subsystem ?
Why two iio device nodes cannot be open together ?

Thanks in advance !

Re: IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Jonathan Cameron]

On 07/31/14 18:07, Aniroop Mathur wrote:
> Dear IIO Community,
> Greetings !!
> 
> I am Aniroop Mathur working in Sensors kernel and HAL field.
> I have one question about IIO, for which i need your support.
> 
> I would like to open two file descriptors for IIO device node - /dev/iio:device0
> int fd1 = open("/dev/iio:device0",O_RDONLY);
> int fd2 = open("/dev/iio:device0",O_RDONLY);
> 
> But, only first open call succeeds.
> The second open calls fails with error "Device or Resource busy".
> 
> In normal input device, we can open as many event node file
> descriptors as we like.
> int fd1 = open("/dev/input/event1");
> int fd2 = open("/dev/input/event1");
> 
> Both calls succeeds for input subsystem case.
> 
> So, why restriction is present in IIO subsystem ?
Basically a different design descision for the userspace interfaces.  Input moves
a lot of handling and processing into the kernel.  For IIO, which at least sometimes
is dealing with much faster devices, this adds overhead.  Note that we remove
all overhead of description of data from the main data stream to reduce overhead
so that must be described elsewhere (sysfs).

If you really want to do that then we do have a prototype input client driver for IIO
(though it's not seen much work recently).

In theory it is possible to have more userspace exposed buffer associated with
a given IIO device, though right now this isn't actually done.  The intent of that
infrastructure is to provide splitting of data to multiple users within the kernel
(one might be IIO, another input and a third battery monitoring).

Ultimately if you want multiple userspace devices to share a datastream, then it
makes sense to avoid multiple switches in and out of the kernel and do it in userspace
instead.

Jonathan

> Why two iio device nodes cannot be open together ?
Not quite what I think you mean.  You mean, why can you not open the same device node
twice?
> 
> Thanks in advance !
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Aniroop Mathur]

On Sat, Aug 2, 2014 at 4:58 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 07/31/14 18:07, Aniroop Mathur wrote:
>> Dear IIO Community,
>> Greetings !!
>>
>> I am Aniroop Mathur working in Sensors kernel and HAL field.
>> I have one question about IIO, for which i need your support.
>>
>> I would like to open two file descriptors for IIO device node - /dev/iio:device0
>> int fd1 = open("/dev/iio:device0",O_RDONLY);
>> int fd2 = open("/dev/iio:device0",O_RDONLY);
>>
>> But, only first open call succeeds.
>> The second open calls fails with error "Device or Resource busy".
>>
>> In normal input device, we can open as many event node file
>> descriptors as we like.
>> int fd1 = open("/dev/input/event1");
>> int fd2 = open("/dev/input/event1");
>>
>> Both calls succeeds for input subsystem case.
>>
>> So, why restriction is present in IIO subsystem ?
> Basically a different design descision for the userspace interfaces.  Input moves
> a lot of handling and processing into the kernel.  For IIO, which at least sometimes
> is dealing with much faster devices, this adds overhead.  Note that we remove
> all overhead of description of data from the main data stream to reduce overhead
> so that must be described elsewhere (sysfs).
>
> If you really want to do that then we do have a prototype input client driver for IIO
> (though it's not seen much work recently).
>

I did not understood your point clearly. (prototype input client driver for IIO)
So you mean it is possible to open same iio device node twice by some means ?
If so, could you please explain how to do it ?

Actually, main aim is to create an IIO device Simulator.
For this I need to write data to IIO device node from a user space application
when hardware chip is actually off.
So, even after opening iio device node,
can we write the data to IIO device node from user space ?
(I do not see write function in below fileops)

static const struct file_operations iio_event_chrdev_fileops = {
     .read =  iio_event_chrdev_read,
     .poll =  iio_event_poll,
     .release = iio_event_chrdev_release,
     .owner = THIS_MODULE,
     .llseek = noop_llseek,
};

> In theory it is possible to have more userspace exposed buffer associated with
> a given IIO device, though right now this isn't actually done.  The intent of that
> infrastructure is to provide splitting of data to multiple users within the kernel
> (one might be IIO, another input and a third battery monitoring).
>
> Ultimately if you want multiple userspace devices to share a datastream, then it
> makes sense to avoid multiple switches in and out of the kernel and do it in userspace
> instead.
>
> Jonathan
>
>> Why two iio device nodes cannot be open together ?
> Not quite what I think you mean.  You mean, why can you not open the same device node
> twice?

Yes, right. Thanks for the correction. :)

>>
>> Thanks in advance !
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
Thanks,
Aniroop Mathur

Re: IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Jonathan Cameron]

On 02/08/14 14:07, Aniroop Mathur wrote:
> On Sat, Aug 2, 2014 at 4:58 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> On 07/31/14 18:07, Aniroop Mathur wrote:
>>> Dear IIO Community,
>>> Greetings !!
>>>
>>> I am Aniroop Mathur working in Sensors kernel and HAL field.
>>> I have one question about IIO, for which i need your support.
>>>
>>> I would like to open two file descriptors for IIO device node - /dev/iio:device0
>>> int fd1 = open("/dev/iio:device0",O_RDONLY);
>>> int fd2 = open("/dev/iio:device0",O_RDONLY);
>>>
>>> But, only first open call succeeds.
>>> The second open calls fails with error "Device or Resource busy".
>>>
>>> In normal input device, we can open as many event node file
>>> descriptors as we like.
>>> int fd1 = open("/dev/input/event1");
>>> int fd2 = open("/dev/input/event1");
>>>
>>> Both calls succeeds for input subsystem case.
>>>
>>> So, why restriction is present in IIO subsystem ?
>> Basically a different design descision for the userspace interfaces.  Input moves
>> a lot of handling and processing into the kernel.  For IIO, which at least sometimes
>> is dealing with much faster devices, this adds overhead.  Note that we remove
>> all overhead of description of data from the main data stream to reduce overhead
>> so that must be described elsewhere (sysfs).
>>
>> If you really want to do that then we do have a prototype input client driver for IIO
>> (though it's not seen much work recently).
>>
> 
> I did not understood your point clearly. (prototype input client driver for IIO)
> So you mean it is possible to open same iio device node twice by some means ?
Not really.  What you can do is add an input device driver that uses an iio device
as the source of it's data.  That way you end up with all the normal input
interfaces.  This was originally intended for multipurpose devices such as
accelerometers or cases where a clear input device is wired up to a general
purpose ADC (joysticks etc).
> If so, could you please explain how to do it ?
> 
> Actually, main aim is to create an IIO device Simulator.
Cool
> For this I need to write data to IIO device node from a user space application
> when hardware chip is actually off.
Sure, though if you paired a DAC device with an ADC (or a modification of
our existing simulated driver - the dummy driver still in staging).

> So, even after opening iio device node,
> can we write the data to IIO device node from user space ?
> (I do not see write function in below fileops)

Indeed.  Lars was working on some buffered support for DACs but hasn't
yet submitted it for mainline inclusion.  Lars how is the buffered output
stuff coming along?

Right now output devices are only supported via the sysfs interfaces.
> 
> static const struct file_operations iio_event_chrdev_fileops = {
>      .read =  iio_event_chrdev_read,
>      .poll =  iio_event_poll,
>      .release = iio_event_chrdev_release,
>      .owner = THIS_MODULE,
>      .llseek = noop_llseek,
> };
> 
>> In theory it is possible to have more userspace exposed buffer associated with
>> a given IIO device, though right now this isn't actually done.  The intent of that
>> infrastructure is to provide splitting of data to multiple users within the kernel
>> (one might be IIO, another input and a third battery monitoring).
>>
>> Ultimately if you want multiple userspace devices to share a datastream, then it
>> makes sense to avoid multiple switches in and out of the kernel and do it in userspace
>> instead.
>>
>> Jonathan
>>
>>> Why two iio device nodes cannot be open together ?
>> Not quite what I think you mean.  You mean, why can you not open the same device node
>> twice?
> 
> Yes, right. Thanks for the correction. :)
> 
>>>
>>> Thanks in advance !
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
> Thanks,
> Aniroop Mathur
> 

Re: IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Lars-Peter Clausen]

On 08/02/2014 06:57 PM, Jonathan Cameron wrote:
[...]
>> So, even after opening iio device node,
>> can we write the data to IIO device node from user space ?
>> (I do not see write function in below fileops)
>
> Indeed.  Lars was working on some buffered support for DACs but hasn't
> yet submitted it for mainline inclusion.  Lars how is the buffered output
> stuff coming along?

I still need to do the re-write you wanted me to do, otherwise its working 
fine ;)

- Lars

Re: IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Aniroop Mathur]

On Sun, Aug 3, 2014 at 1:41 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 08/02/2014 06:57 PM, Jonathan Cameron wrote:
> [...]
>
>>> So, even after opening iio device node,
>>> can we write the data to IIO device node from user space ?
>>> (I do not see write function in below fileops)
>>
>>
>> Indeed.  Lars was working on some buffered support for DACs but hasn't
>> yet submitted it for mainline inclusion.  Lars how is the buffered output
>> stuff coming along?
>
>
> I still need to do the re-write you wanted me to do, otherwise its working
> fine ;)
>

Great :)
So, it is possible to write data to iio fd ?

char *data;
int nbytes = 24;
int res = write(iio_fd, data, nbytes);

This will work fine ?

If yes, can you please help to tell where is write function defined ?
I could find only read function here
static const struct file_operations iio_event_chrdev_fileops = {
     .read =  iio_event_chrdev_read,
     .poll =  iio_event_poll,
     .release = iio_event_chrdev_release,
     .owner = THIS_MODULE,
     .llseek = noop_llseek,
}

> - Lars
>

Thanks,
Aniroop

Re: IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Lars-Peter Clausen]

On 08/03/2014 11:32 AM, Aniroop Mathur wrote:
> On Sun, Aug 3, 2014 at 1:41 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>> On 08/02/2014 06:57 PM, Jonathan Cameron wrote:
>> [...]
>>
>>>> So, even after opening iio device node,
>>>> can we write the data to IIO device node from user space ?
>>>> (I do not see write function in below fileops)
>>>
>>>
>>> Indeed.  Lars was working on some buffered support for DACs but hasn't
>>> yet submitted it for mainline inclusion.  Lars how is the buffered output
>>> stuff coming along?
>>
>>
>> I still need to do the re-write you wanted me to do, otherwise its working
>> fine ;)
>>
>
> Great :)
> So, it is possible to write data to iio fd ?

No you can't. At least not with the upstream code. What exactly is it that 
you want to do with this?

- Lars

Re: IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Aniroop Mathur]

On Mon, Aug 4, 2014 at 12:48 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 08/03/2014 11:32 AM, Aniroop Mathur wrote:
>>
>> On Sun, Aug 3, 2014 at 1:41 PM, Lars-Peter Clausen <lars@metafoo.de>
>> wrote:
>>>
>>> On 08/02/2014 06:57 PM, Jonathan Cameron wrote:
>>> [...]
>>>
>>>>> So, even after opening iio device node,
>>>>> can we write the data to IIO device node from user space ?
>>>>> (I do not see write function in below fileops)
>>>>
>>>>
>>>>
>>>> Indeed.  Lars was working on some buffered support for DACs but hasn't
>>>> yet submitted it for mainline inclusion.  Lars how is the buffered
>>>> output
>>>> stuff coming along?
>>>
>>>
>>>
>>> I still need to do the re-write you wanted me to do, otherwise its
>>> working
>>> fine ;)
>>>
>>
>> Great :)
>> So, it is possible to write data to iio fd ?
>
>
> No you can't. At least not with the upstream code. What exactly is it that
> you want to do with this?
>

Okay :)
Actually, I am working on IIO device simulator android application.
This simulator will record the sensor data first and then replay it again.
For recording, we can read the data from iio device node and store it some file.
And for replay, we need to write the recorded data back to iio device node.
But as you said, from hal/application we cannot write the data to iio
device node
and therefore i am stuck how to replay back the recorded data.

In normal input device node, we can both read and write data,
so simulator is working fine for this case.
I was hoping to do the same with IIO device node.

Is there any scope this facility will be included in future for IIO ? :)

Also, few days back I posted this query on Linuxquestions.org.
http://www.linuxquestions.org/questions/linux-general-1/iio-why-cannot-open-same-iio-device-node-twice-4175512869/

I think now this thread could be marked as solved.
Title - IIO: Why cannot open same iio device node twice ?

May be if it is okay, please help to put the answer upon the link above.

>From my side,
Below is the answer i am able to derive from above discussion:

"Basically IIO is a different design for the userspace interfaces.
IIO mainly deals with much faster devices so overhead of description of data
has been removed to avoid overhead in kernel.

An alternate solution would be to use a input client driver for IIO,
which can uses an iio device as the source of it's data.
That way we end up with all the normal input interfaces.

Ultimately if we want multiple user applications to share a datastream,
then it makes sense to avoid multiple switches in and out of the kernel
and do it in userspace instead."

Is the answer okay ?

> - Lars

Re: IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Lars-Peter Clausen]

On 08/04/2014 05:11 PM, Aniroop Mathur wrote:
> On Mon, Aug 4, 2014 at 12:48 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>> On 08/03/2014 11:32 AM, Aniroop Mathur wrote:
>>>
>>> On Sun, Aug 3, 2014 at 1:41 PM, Lars-Peter Clausen <lars@metafoo.de>
>>> wrote:
>>>>
>>>> On 08/02/2014 06:57 PM, Jonathan Cameron wrote:
>>>> [...]
>>>>
>>>>>> So, even after opening iio device node,
>>>>>> can we write the data to IIO device node from user space ?
>>>>>> (I do not see write function in below fileops)
>>>>>
>>>>>
>>>>>
>>>>> Indeed.  Lars was working on some buffered support for DACs but hasn't
>>>>> yet submitted it for mainline inclusion.  Lars how is the buffered
>>>>> output
>>>>> stuff coming along?
>>>>
>>>>
>>>>
>>>> I still need to do the re-write you wanted me to do, otherwise its
>>>> working
>>>> fine ;)
>>>>
>>>
>>> Great :)
>>> So, it is possible to write data to iio fd ?
>>
>>
>> No you can't. At least not with the upstream code. What exactly is it that
>> you want to do with this?
>>
>
> Okay :)
> Actually, I am working on IIO device simulator android application.
> This simulator will record the sensor data first and then replay it again.
> For recording, we can read the data from iio device node and store it some file.
> And for replay, we need to write the recorded data back to iio device node.
> But as you said, from hal/application we cannot write the data to iio
> device node
> and therefore i am stuck how to replay back the recorded data.
>
> In normal input device node, we can both read and write data,
> so simulator is working fine for this case.
> I was hoping to do the same with IIO device node.
>
> Is there any scope this facility will be included in future for IIO ? :)

Injection of data into the output stream of a IIO device is something that's 
not planed at the moment I think. The writing support Jonathan referred to 
is for writing data to actual hardware (e.g. a DAC). If you think it will be 
useful to have support for injecting data into a abitrary IIO datastream 
rather than e.g. having dummy loopback device you can submit a patch which 
adds support for this.

- Lars

Re: IIO: Why cannot open two iio device node file descriptors simultaneously ?

[Aniroop Mathur]

On Mon, Aug 4, 2014 at 10:50 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 08/04/2014 05:11 PM, Aniroop Mathur wrote:
>>
>> On Mon, Aug 4, 2014 at 12:48 PM, Lars-Peter Clausen <lars@metafoo.de>
>> wrote:
>>>
>>> On 08/03/2014 11:32 AM, Aniroop Mathur wrote:
>>>>
>>>>
>>>> On Sun, Aug 3, 2014 at 1:41 PM, Lars-Peter Clausen <lars@metafoo.de>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 08/02/2014 06:57 PM, Jonathan Cameron wrote:
>>>>> [...]
>>>>>
>>>>>>> So, even after opening iio device node,
>>>>>>> can we write the data to IIO device node from user space ?
>>>>>>> (I do not see write function in below fileops)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Indeed.  Lars was working on some buffered support for DACs but hasn't
>>>>>> yet submitted it for mainline inclusion.  Lars how is the buffered
>>>>>> output
>>>>>> stuff coming along?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I still need to do the re-write you wanted me to do, otherwise its
>>>>> working
>>>>> fine ;)
>>>>>
>>>>
>>>> Great :)
>>>> So, it is possible to write data to iio fd ?
>>>
>>>
>>>
>>> No you can't. At least not with the upstream code. What exactly is it
>>> that
>>> you want to do with this?
>>>
>>
>> Okay :)
>> Actually, I am working on IIO device simulator android application.
>> This simulator will record the sensor data first and then replay it again.
>> For recording, we can read the data from iio device node and store it some
>> file.
>> And for replay, we need to write the recorded data back to iio device
>> node.
>> But as you said, from hal/application we cannot write the data to iio
>> device node
>> and therefore i am stuck how to replay back the recorded data.
>>
>> In normal input device node, we can both read and write data,
>> so simulator is working fine for this case.
>> I was hoping to do the same with IIO device node.
>>
>> Is there any scope this facility will be included in future for IIO ? :)
>
>
> Injection of data into the output stream of a IIO device is something that's
> not planed at the moment I think. The writing support Jonathan referred to
> is for writing data to actual hardware (e.g. a DAC). If you think it will be
> useful to have support for injecting data into a abitrary IIO datastream
> rather than e.g. having dummy loopback device you can submit a patch which
> adds support for this.
>
> - Lars
>

Okay :)
I will try to add the write feature and submit the patch soon for review.

Thank you so much for your support ! :)

-- Aniroop