Interested in working on a BeagleBone GSoC project

Good day everyone.

I am studying the IIO documentation files and the linux kernel driver-model for the debugging tools project. I’d like to have some more details and to express some ideas I am thinking about :
If I understand it right an evtest-like tool should be able to list all IIO devices connected using the sysfs interface and list their open channels, tiggers, and buffers, also it should poll them to see if they are returning valid values, am I correct ?

I’m a linux kernel newbie so I did not completely understand proposal number 2, could mr Yau be so kind to explain it in a bit more detailed way ?
As I see it a more complex kernel-side debug tool should offer more detailed information about the iio_dev, iio_info, iio_chan_spec, ecc structures by exposing to userspace the values of the structure members, the buffers sizes, ecc and maybe offering a iio_info->debug() hook function in each iio_device to let the driver developer log more device specific debug informations and error logs.

All the informations could be exposed by another system like debugfs (there were some debugfs related calls in iio_core, I’ll look at them tomorrow).
These are just possibilites I am considering, as I learn more about the iio drivers and the kernel I’ll post more specific stuff.
I’d love to discuss these ideas with Hunyue Yau (and to ask him a LOT of questions :)), how can I contact him ?

PS:My beaglebone will finally arrive tomorrow.

Regards,
Alessandro Osima.

Hi Alessandro,

Good day everyone.

I am studying the IIO documentation files and the linux kernel
driver-model for the debugging tools project. I'd like to
have some more details and to express some ideas I am
thinking about :
If I understand it right an evtest-like tool should be able to
list all IIO devices connected using the sysfs interface and
list their open channels, tiggers, and buffers, also it
should poll them to see if they are returning valid values,
am I correct ?

This is somewhat open to interpretation. When I wrote up the
suggested idea, what I was thinking of is along the lines of:
- It can take the name of a IIO device on the command line and
dump what it knows about it.
- It will then dump data and timing information about it.

The reason it isn't very concrete is simply due to differences
with the input subsystem. In the input subsystem, there is the
concept of event devices which is another layer.

There is a similar tool in Android, getevents, that is similar to
evtest. Comparatively speaking, getevents is much simplier but
less useful. Obvious differences:
1. It doesn't decode things as much (it provides the information
as hex values)
2. It defaults to dumping all devices instead of the selected
device.

I suggest taking a look at evtest.c (the entire program is a
single C file, just search for it with your favorite search
engine). If your system is setup right, you can even run it on a
desktop system to dump keyboard or mouse information.

I'm a linux kernel newbie so I did not completely understand
proposal number 2, could mr Yau be so kind to explain it in a
bit more detailed way ? As I see it a more complex
kernel-side debug tool should offer more detailed information
about the iio_dev, iio_info, iio_chan_spec, ecc structures by
exposing to userspace the values of the structure members,
the buffers sizes, ecc and maybe offering a iio_info->debug()
hook function in each iio_device to let the driver developer
log more device specific debug informations and error logs.

Explaining the problem in another way -

IIO is a relatively new subsystem. It lacks tools to debug it.
Imagine you are trying to port a driver for an accelerometer to
IIO. You have a legacy driver for the input subsystem.

To test the legacy driver, you could run a simple program like
evtest to dump the values from the accelerometer as you move it
around. The currently is no simple tool like that to test the
newly ported driver. The goal of the problem is to have a way of
testing the newly ported driver.

Above is one way of accomplish this.

Another way is to provide a way to pipe the data from the IIO
subsystem to an event device. i.e. something like
/dev/iio/event0. It would be ioctl() compatible with the
/dev/input/event0 cousin. What this gives us is the ability to
use evtest against the new device to test things. This change
would also let you use a legacy application with a IIO driver.

If you take a look at:
http://us.generation-nt.com/answer/rfc-iio-options-event-
userspace-interface-help-203768792.html

"* Separate evdev from input and share it across both subsystems.
This seemed like a good idea, but evdev is pretty tightly tied to
the input core. Note we would never be sharing input's event
codes. They are too restrictive (with good reason seeing
as they are for 'input' devices!) Basically I expect this could
be done, but would need to be done very carefully so as to not
have any impact on input users. Perhaps it is the right answer,
but its not trivial. (I've cc'd linux-input to get comments
on this option!)"

(2) is basically this.

All the informations could be exposed by another system like
debugfs (there were some debugfs related calls in iio_core,
I'll look at them tomorrow). These are just possibilites I am
considering, as I learn more about the iio drivers and the
kernel I'll post more specific stuff. I'd love to discuss
these ideas with Hunyue Yau (and to ask him a LOT of
questions :)), how can I contact him ?

You can find me on irc as "ds2". I monitor the "#beagle-gsoc"
channel. Sometimes I can be busy but eventually I'll see the
message.

Hi Alessandro,

Good day everyone.

I am studying the IIO documentation files and the linux kernel
driver-model for the debugging tools project. I'd like to
have some more details and to express some ideas I am
thinking about :
If I understand it right an evtest-like tool should be able to
list all IIO devices connected using the sysfs interface and
list their open channels, tiggers, and buffers, also it
should poll them to see if they are returning valid values,
am I correct ?

This is somewhat open to interpretation. When I wrote up the
suggested idea, what I was thinking of is along the lines of:
- It can take the name of a IIO device on the command line and
dump what it knows about it.
- It will then dump data and timing information about it.

The reason it isn't very concrete is simply due to differences
with the input subsystem. In the input subsystem, there is the
concept of event devices which is another layer.

There is a similar tool in Android, getevents, that is similar to
evtest. Comparatively speaking, getevents is much simplier but
less useful. Obvious differences:
1. It doesn't decode things as much (it provides the information
as hex values)
2. It defaults to dumping all devices instead of the selected
device.

I suggest taking a look at evtest.c (the entire program is a
single C file, just search for it with your favorite search
engine). If your system is setup right, you can even run it on a
desktop system to dump keyboard or mouse information.

There are also iio test utils in the kernel tree hidden in staging/:

[koen@rrMBP kernel]$ ls -1 drivers/staging/iio/Documentation/
dac
device.txt
generic_buffer.c
iio_event_monitor.c
iio_utils.h
inkernel.txt
light
overview.txt
ring.txt
sysfs-bus-iio-ad7192
sysfs-bus-iio-adc-ad7280a
sysfs-bus-iio-dds
sysfs-bus-iio-impedance-analyzer-ad5933
sysfs-bus-iio-light
sysfs-bus-iio-light-tsl2583
sysfs-bus-iio-trigger-sysfs
trigger.txt

ADI took that as a base and created a neat demo from that:

  http://www.spinics.net/lists/linux-iio/msg07842.html

regards,

Koen

The reason it isn’t very concrete is simply due to differences

with the input subsystem. In the input subsystem, there is the
concept of event devices which is another layer.

There is a similar tool in Android, getevents, that is similar to
evtest. Comparatively speaking, getevents is much simplier but
less useful. Obvious differences:

  1. It doesn’t decode things as much (it provides the information
    as hex values)
  2. It defaults to dumping all devices instead of the selected
    device.

I suggest taking a look at evtest.c (the entire program is a
single C file, just search for it with your favorite search
engine). If your system is setup right, you can even run it on a
desktop system to dump keyboard or mouse information.

I’m studying evtest source code now, I’ve compiled and used it on a debian pc and on the beaglebone.
A very basic similar iio oriented tool could work in the following way:

iiotest [device] -c channel -p refreshdeltatime -i

where device is the /sys/bus/iio/devices/deviceN or just the device name, -c is the channel to poll (is also possibile possibile to poll all channels at the same time), -p is an int that represent how many times the channels must be polled. The -i option print more informations about the selected device like all the triggers, buffers, ecc

If no device is specified the program will print informations about all the devices and ask the user to select just one device to poll.

This is just an example, I’ll add more specific informations as I learn more about the drivers.

To test the legacy driver, you could run a simple program like
evtest to dump the values from the accelerometer as you move it
around. The currently is no simple tool like that to test the
newly ported driver. The goal of the problem is to have a way of
testing the newly ported driver.

Above is one way of accomplish this.

Another way is to provide a way to pipe the data from the IIO
subsystem to an event device. i.e. something like
/dev/iio/event0. It would be ioctl() compatible with the
/dev/input/event0 cousin. What this gives us is the ability to
use evtest against the new device to test things. This change
would also let you use a legacy application with a IIO driver.

If you take a look at:
http://us.generation-nt.com/answer/rfc-iio-options-event-
userspace-interface-help-203768792.html

“* Separate evdev from input and share it across both subsystems.
This seemed like a good idea, but evdev is pretty tightly tied to
the input core. Note we would never be sharing input’s event
codes. They are too restrictive (with good reason seeing
as they are for ‘input’ devices!) Basically I expect this could
be done, but would need to be done very carefully so as to not
have any impact on input users. Perhaps it is the right answer,
but its not trivial. (I’ve cc’d linux-input to get comments
on this option!)”

(2) is basically this

This sure is a better approach, I’ll look into it and post some ideas as soon as I can.

There are also iio test utils in the kernel tree hidden in staging/:

[koen@rrMBP kernel]$ ls -1 drivers/staging/iio/Documentation/
dac
device.txt
generic_buffer.c
iio_event_monitor.c
iio_utils.h
inkernel.txt
light
overview.txt
ring.txt
sysfs-bus-iio-ad7192
sysfs-bus-iio-adc-ad7280a
sysfs-bus-iio-dds
sysfs-bus-iio-impedance-analyzer-ad5933
sysfs-bus-iio-light
sysfs-bus-iio-light-tsl2583
sysfs-bus-iio-trigger-sysfs
trigger.txt

ADI took that as a base and created a neat demo from that:

http://www.spinics.net/lists/linux-iio/msg07842.html

Reading the iio_utils.* files is definitely on my to-read list, by following http://www.spinics.net/lists/linux-iio/msg07842.html I found this http://sourceforge.net/projects/iioutils/?source=dlp project, It’s an unfinished iio userspace library, It will be very useful for my project.

Also I just received my beaglebone, I’ll start experimenting with the IIO drivers and a VCNL 4000 (http://adafruit.com/products/466) I had lying around as soon as possible.

You can find me on irc as “ds2”. I monitor the “#beagle-gsoc
channel. Sometimes I can be busy but eventually I’ll see the
message.

Great !! My irc nick is “asion”.

I’d like to thank Hunyue,Koen and Tom for your invaluable help, I’m having a really fun time studying for gsoc :).

Regards,
Alessandro Osima.

Sorry for all the useless citations, I honestly don’t how that happened :).

[..]

so I just received my beaglebone, I'll start experimenting with the IIO drivers and a VCNL 4000 (http://adafruit.com/products/466) I had lying around as soon as possible.

I use a http://www.pololu.com/catalog/product/1268 in one of my projects, that gives you 3 iio devices. Well, I used that *and* a vcnl4000, so 4 iio devices :slight_smile: The downside of the miniimuv2 is that it doesn't break out the interrupt pin, which you need to high frequency updates.

regards,

Koen

I use a http://www.pololu.com/catalog/product/1268 in one of my projects, that gives you 3 iio devices. Well, I used that and a vcnl4000, so 4 iio devices :slight_smile: The downside of the miniimuv2 is that it doesn’t break out the interrupt pin, which you need to high frequency updates.

Nice !!! I am definitely going to buy this.
And now you have made me curious :slight_smile: what’s your project about ?

It's a hexapod robot: http://www.flickr.com/photos/koenkooi/8443241503/in/photostream

It’s a hexapod robot: http://www.flickr.com/photos/koenkooi/8443241503/in/photostream

Cool !!! I’ve always wanted to make one of those (and one day I will).

By the way I’m studying the input drivers, evtest and evdev and playing with the beagle kernel. I’ll post some more specific ideas tormorow or friday, the applications period is getting closer :).

Hello Everyone.

In the past days I’ve been studying to find a way to abstract evdev from the input_core subsystem, so we can use it as a userspace interface for the iio drivers.

The problem is that the current evdev implementation is too entangled with the input core subsystem, in particular the input devices initialisation and removal phases will require to rewrite a big part of input_core to realize a truly clean interface.
Some solutions are possible like embedding an iio_dev structure in input_handle and using it to communicate with the iio drivers and some iio specific handler functions, the result of this operations will likely create a giant poorly engineered mess.

After much considerations, studying and a lot of help and tips from Hunyue we have decided that implementing a new, more general subsystem is a better idea.

But how this new system should be organized, and how should it work ?
My idea is that it should only offer an interface to all character devices for kernel/userspace communication handling only the creation and removal of files form the /dev directory, all the actual files operations like read/write/open, ecc will be left to the various subsystems to implement troughtout functions handles registered with the system.

For example let’s say that iio needs a new userspace interface for it’s VCNL 4000 drivers.
What iio will do is to ask nevdev ( == new evdev, this is definitely a temporal name ;)) for a new file in it’s /dev/nevdev directory and pass it’s own file_operations structure. Nevdev will create and register a new file in /dev named (for example) nevdev0 and every time userspace will read or write to it the functions that iio registered will be called.
This means that every subsystem, not only iio or input_core can implement it’s own events and ioctls calls offering a really abstract interface.

Now let’s delve into an overview of the possible api this system will offer .

Like a lot of the other kernel subsystem nevdev will offer the usual register/unregister functions

-int nevdev_register_interface(nevdev_handle * interface, struct device * dev)

-void nevdev_unregister interface(nevdev_handle * interface)

the nevdev_handle is a structure containing some nevdev related thinks like a spinlock a cdev and a device structure, the drivers will have to register two things, a file_operations structure and their device_core device structure.

-struct nevdev_handle* nevdev_allocate_struct(struct file_operations * fops)

this function will allocate nevdev_handle and place fops inside it.
Internally nevdev will have a list of nevdev_handle corresponding to all the registered devices. Every time a new device is registered with int nevdev_register_interface(nevdev_handle * interface) nevdev will:
1:create a new device_core struct device using dev (the second argument in nevdev_register_interface) as a parent and a nevdev global device class as the device class, this way all the newly registered devices will stay in /sys/class/nevdev ready to be exported to /dev/nevdev by udev
2:create a new cdev character device and link it with the fops file_operations struct passed in nevdev_allocate_device.
3:register both with input_core, the hotplug event resulting from this will be intercepted by udev thanks to simple script and new nodes will be created in /dev/nevdev.
I believe nevdev will have is own dinamically allocated major number with the minors corresponding to every newly registered device.
This approach is very similar to the one the current evdev use.

Every time a file_operations syscall arrives it will be intercepted by nevdev first and then sent to the selected device via the registered file_operations struct, this is done in case we need to do some housekeeping (like when we receive an open() or release() call) and because nevdev will offer some global ioctls events for subsystem wide informations.

This is the possible structure of this new subsystem (there may be errors, please notice me if you found some), of course it will reside in a separate kernel module.

One thing I am still thinking about is how to distinguish to wich subsystem a file is registered, it could be as a global ioctls event that asks wich subsystem is the file registered with. This colud be inplemented as a field in nevdev_handle or better as an handle function passed by a subsystem (like iio,input_core, ecc) to nevdev during registration. What do you think ?
With this question solved another ioctls could find all the names of the files registered with a single subsystem and pass them to userspace.

This is the project I would like to present for this year gsoc, what do you think about it ? Do you believe there are problems with this approach ? What can be done better? Should I add some other things (other than the timeline, I’m still thinking about it) for the final application ? I’d love to receive some feedback.

PS for Hunyue: I’ll contact the input_core guys first thing next morning, promise, I just want to wait a while and see if someone think that there is something horribly wrong in this project.

I’ll post a more detailed timeline in the following days, a possible “stretch goal” could be modding the iio core to work with nevdev.

Thanks everyone for reading this loooooooooong post, hope It was at least a bit interesting :).

Regards,
Alessandro Osima.

I have sent an email about my proposal to linux-input (http://www.spinics.net/lists/linux-input/msg25581.html) as requested, since I don’t have Hunyue mail I couldn’t CC him (sorry).

Hello Everyone.

Can someone be so kind to give me some feedback on my application (http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/asion/1#).
Hunyue Yau already gave me a ton of useful tips but a different opinion from other mentors would be very useful.

Regards,
Alessandro Osima.

beagleApp.pdf (64.3 KB)