|Deletions are marked like this.||Additions are marked like this.|
|Line 146:||Line 146:|
|UPDATE: All instances in IIO have been patched or claimed.|
|Line 147:||Line 148:|
|If you're still interested in the topic, look elsewhere in staging drivers.
Those would not need to be claimed as they are not IIO tasks.
These tasks are for you to get familiar with the IIO subsystem. You do not need to claim these via the Outreachy tasks page. For IIO related questions you can join #linux-iio IRC channel (server irc.oftc.net).
Please email your solutions to amsfield22 at gmail dot com and daniel.baluta at gmail dot com. Your email should have the subject Task XX: Short task description
Experimenting with IIO subsystem
For this we will use two kernel modules found in drivers/iio/dummy:
iio_dummy_evgen.ko - generates fake events interrupts to be used by the iio_dummy example driver
implementation for this module is in iio_dummy_evgen.c
iio_dummy.ko - example IIO driver to demonstrate existing functionality
core implementation can be found in iio_simple_dummy.c
buffer functionality is implemented in iio_simple_dummy_buffer.c
events functionality is implemented in iio_simple_dummy_events.c
Dummy modules compilation
You need to select the following config options:
CONFIG_IIO_DUMMY_EVGEN - for building iio_dummy_evgen kernel module
CONFIG_IIO_SIMPLE_DUMMY - for building iio_dummy kernel module
CONFIG_IIO_SIMPLE_DUMMY_EVENTS, CONFIG_IIO_SIMPLE_DUMMY_BUFFER should be selected for events and buffer functionality.
CONFIG_IIO_CONFIGFS - for creating the dummy device under configfs
- Mount the configfs filesystem: read Documentation/iio/iio_configfs.txt
Use the following commands for modules compilation:
$ make drivers/iio/dummy/iio_dummy_evgen.ko
$ make drivers/iio/dummy/iio_dummy.ko
Use the following commands for module loading:
$ insmod iio_dummy_evgen.ko
$ insmod iio_dummy.ko
Use the following command to create your dummy device under the configfs filesystem:
$ mkdir /config/iio/devices/dummy/my_dummy_device
- Show that the modules were successfully loaded.
- lsmod | grep dummy
- ls -l /config/iio/devices/dummy/
- ls -l /sys/bus/iio/devices/iio:device0/
- ls -l /sys/bus/iio/devices/iio_evgen/
- Add channels for a 3-axis compass to iio_simple_dummy module.
- Show that channels were successfully added
- ls -l /sys/bus/iio/devices/iio:device0/
- ls -l /sys/bus/iio/devices/iio:device0/scan_elements
- create a patch with your changes
- channel type for a compass is IIO_MAGN
- users should be able to read raw readings from each axis
- users should be able to read a shared scale
- users should be able to access data via a buffer
- data is unsigned, resolution is 16 bits, storage is 16 bits
- compass doesn't support events
IIO event monitor
IIO event monitor is an user space example application which reads events from IIO layer and pretty prints the results. Implementation can be found in iio_event_monitor.c under tools/iio/. BR
compile iio_event_monitor.c to obtain an executable called iio_event_monitor.
- send us the command(s) used to successfully compile iio_event_monitor.c
Read events using iio_event_monitor
- run iio_event_monitor without arguments to figure out how it should be used
- read events from iio_dummy module
- Events are generated by iio_dummy_evgen via sysfs (look inside /sys/bus/iio/devices/iio_evgen/)
- send us the commands used to read/generate the events
Create triggers using configfs interface.
- read Documentation/iio/iio_configfs.txt in order to create a software trigger named t1.
- where in the sysfs hierarchy does the trigger resides?
- sends us the commands used to create the trigger
Read samples from buffer generated by the iio_dummy module.
- compile iio_generic_buffer.c from tools/iio. This program will be used to read data from buffer.
have a look at ./iio_generic_buffer -h options. You will use the trigger t1 created with the previous tasks and iio_dummy_part_no for IIO device.
- send us the full command history
Note for all IIO Coding Tasks:
- Please use the task page to claim the driver you are going to patch.
Please 'CC email@example.com on all questions related to this so everyone can benefit.
Task 1: Replace IIO_DEV_ATTR_* with IIO_CHAN_INFO_*
As the IIO subsystem evolves, attributes that were once privately defined become standard and hence a special global define is used. This kind of evolution means we can update existing drivers to use the new defines.
Review this recently submitted patch:
- commit e0f3fc9b47e6 iio: accel: sca3000_core: implemented IIO_CHAN_INFO_SAMP_FREQ
Note that aside from looking at the patch itself, you can find the email chatter about it in the linux-iio mailing list.
Find a driver in the IIO staging directory that has one or more IIO_DEV_ATTR* that can be updated to IIO_CHAN_INFO* attributes.
UPDATE: No instances remain in drivers/staging. If you have not created a patch for this yet, please look in drivers/iio.
- You'll get a basic understanding of how the attributes are defined and used while doing this work. That'll take some exploring.
- The example patch I referenced startled me at first with the diffstat! You'll find that it's movement of code, not so much creation of new code that led to so many changes.
Task 2: Use sparse for endianess verification
With this task you will learn about the endianness conversions.
Use the following commands to check for endianness warnings in IIO code:
make C=2 CF=-D__CHECK_ENDIAN__ drivers/iio/
make C=2 CF=-D__CHECK_ENDIAN__ drivers/staging/iio/
In order to get relevant results from sparse on IIO you need to select for building the corresponding modules.
You either run make menuconfig and manually go to Drivers -> IIO and select each driver with Y or M for build.
Or run make allyesconfig before running sparse command.
UPDATE: All instances in IIO have been patched or claimed.
If you're still interested in the topic, look elsewhere in staging drivers. Those would not need to be claimed as they are not IIO tasks.