|
Size: 6117
Comment: Add also IIO non-staging dir for sparse endianess check
|
← Revision 71 as of 2018-02-18 17:35:36 ⇥
Size: 6827
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from IIO cleanup | = Welcome to IIO tasks page = |
| Line 3: | Line 3: |
| 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). | This page is dedicated to students applying for GSoC/Outreachy programs. |
| Line 5: | Line 5: |
| 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''' |
It also aims to help newcomers getting started with the Industrial IO subsystem, offering pointers to documentation and small tasks. For GSoC/Outreachy students: Please use a single email thread for communication. During the application always reply to this thread if you have a question or sending the solution for a task. The email should have the following format: subject: GSoC IIO project: Your Name body: <short description of content: e.g Task 01 / Question about the schedule / etc> <the actual email body> |
| Line 12: | Line 23: |
| * {{{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}}} |
|
| Line 18: | Line 27: |
| * {{{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}}} |
|
| Line 22: | Line 33: |
| * {{{CONFIG_IIO_DUMMY_EVGEN}}} - for building {{{iio_dummy_evgen}}} kernel module | * {{{CONFIG_IIO_CONFIGFS}}} - for creating the dummy device under configfs |
| Line 25: | Line 36: |
| * {{{CONFIG_IIO_CONFIGFS}}} - for creating the dummy device under configfs |
* {{{CONFIG_IIO_DUMMY_EVGEN}}} - for building {{{iio_dummy_evgen}}} kernel module |
| Line 41: | Line 51: |
| * Show that config options for IIO dummy modules were correctly selected * send the content of the following command grep IIO .config |
|
| Line 42: | Line 54: |
| Task 02: | |
| Line 48: | Line 61: |
| Task 02: |
Task 03: |
| Line 55: | Line 67: |
| Line 66: | Line 77: |
| 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]] | 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>> |
| Line 68: | Line 79: |
| Task 03: | Task 04: |
| Line 75: | Line 86: |
| Task 04: | Task 05: |
| Line 86: | Line 97: |
| Task 05: | Task 06: |
| Line 89: | Line 100: |
| * read Documentation/iio/iio_configfs.txt in order to create a software trigger named t1. | * read Documentation/iio/iio_configfs.txt in order to create an hrtimer software trigger named t1. |
| Line 93: | Line 104: |
| Task 06: | Task 07: |
| Line 100: | Line 111: |
| = Coding Tasks = | |
| Line 101: | Line 113: |
| = Coding Task = | == Coding Task 1 == |
| Line 103: | Line 115: |
| == Task 1: Replace IIO_DEV_ATTR_* with IIO_CHAN_INFO_* == | Send 2 cleanup patches to the linux kernel. |
| Line 105: | Line 117: |
| 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. | Important: |
| Line 107: | Line 119: |
| Review this recently submitted patch: commit e0f3fc9b47e6 iio: accel: sca3000_core: implemented IIO_CHAN_INFO_SAMP_FREQ |
* patches should be for code in drivers/staging/ * use tools like checkpatch.pl, sparse or coccinelle to find cleanups. |
| Line 111: | Line 122: |
| http://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/commit/?h=testing&id=e0f3fc9b47e61bb5d79f2bb8684d80eee5aaac99 | Useful links: * [[https://kernelnewbies.org/Outreachyfirstpatch | Outreachy First Patch]] * [[https://www.youtube.com/watch?v=LLBrBBImJt4 | Greg KH presentation - Send your first patch]] |
| Line 113: | Line 126: |
| == Coding Task 2 == | |
| Line 114: | Line 128: |
| Note that aside from looking at the patch itself, you can find the email chatter about it in the linux-iio mailing list. | drivers/staging directory is the place where drivers that aren't yet fit to be merged into the main portion of the kernel for various reasons: code quality, non standard interfaces, etc. Grab a driver from drivers/staging/iio and try to move it into drivers/iio. |
| Line 116: | Line 130: |
| 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. | Important: |
| Line 118: | Line 132: |
| Note: * 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. |
* read IIO documentation and try to understand why the driver you picked is not yet ready to be merged into drivers/iio. * send an email to linux-iio mailing list with your idea for changes to be done in order to move the driver out of staging |
| Line 122: | Line 135: |
| == Task 2: Use sparse for endianess verification == | == Coding Task 3 == |
| Line 124: | Line 137: |
| See article here https://lwn.net/Articles/205624/. With this task you will learn about the endianness conversions. | Each driver that supports both SPI and I2C has the following structure: * common part * I2C part * SPI part |
| Line 126: | Line 142: |
| 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/ Global note: |
It seems that there is a lot of duplicate/similar code for I2C/SPI parts. Have a look at the following drivers: * drivers/iio/accel/mma7455_{core,spi,i2c}.c * drivers/iio/pressure/st_pressure{core,spi,i2c}.c * drivers/iio/magnetometer/hmc5843{core,spi,i2c}.c |
| Line 132: | Line 147: |
| * Please use the task page to claim the driver you are going to patch. * Please stay in staging, for now. Opportunities do exist upstream for those who persist. * Please 'CC outreachy-kernel@googlegroups.com on all questions related to this so everyone can benefit. |
We want to create a common framework for I2C/SPI parts and reuse it for each driver to avoid code duplication. Important: * before starting writing the code send an email to linux-iio list presenting your idea on how do you want to solve this in order to get some feedback. = Resources = * [[http://vger.kernel.org/vger-lists.html#linux-iio | linux-iio]] mailing list. * [[https://www.kernel.org/doc/html/v4.12/driver-api/iio/index.html | IIO documentation]] * [[https://events.static.linuxfound.org/sites/events/files/slides/lceu15_baluta.pdf | IIO presentation]] For questions please send questions in the format mentioned above to daniel.baluta at nxp dot com or the #linux-iio IRC channel (server irc.oftc.net). |
Welcome to IIO tasks page
This page is dedicated to students applying for GSoC/Outreachy programs.
It also aims to help newcomers getting started with the Industrial IO subsystem, offering pointers to documentation and small tasks.
For GSoC/Outreachy students:
Please use a single email thread for communication. During the application always reply to this thread if you have a question or sending the solution for a task. The email should have the following format:
subject: GSoC IIO project: Your Name
body: <short description of content: e.g Task 01 / Question about the schedule / etc> <the actual email body>
Experimenting with IIO subsystem
For this we will use two kernel modules found in drivers/iio/dummy:
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
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
Dummy modules compilation
You need to select the following config options:
CONFIG_IIO_CONFIGFS - for creating the dummy device under configfs
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_DUMMY_EVGEN - for building iio_dummy_evgen kernel module
- 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
Task 01:
- Show that config options for IIO dummy modules were correctly selected
- send the content of the following command grep IIO .config
Task 02:
- 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/
Task 03:
- 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
Hints:
- 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/.
Task 04:
Compile iio_event_monitor:
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
Task 05:
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
Hints
- 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
Generic buffer
Task 06:
Create triggers using configfs interface.
- read Documentation/iio/iio_configfs.txt in order to create an hrtimer software trigger named t1.
- where in the sysfs hierarchy does the trigger resides?
- sends us the commands used to create the trigger
Task 07:
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
Coding Tasks
Coding Task 1
Send 2 cleanup patches to the linux kernel.
Important:
- patches should be for code in drivers/staging/
- use tools like checkpatch.pl, sparse or coccinelle to find cleanups.
Useful links:
Coding Task 2
drivers/staging directory is the place where drivers that aren't yet fit to be merged into the main portion of the kernel for various reasons: code quality, non standard interfaces, etc. Grab a driver from drivers/staging/iio and try to move it into drivers/iio.
Important:
- read IIO documentation and try to understand why the driver you picked is not yet ready to be merged into drivers/iio.
- send an email to linux-iio mailing list with your idea for changes to be done in order to move the driver out of staging
Coding Task 3
Each driver that supports both SPI and I2C has the following structure:
- common part
- I2C part
- SPI part
It seems that there is a lot of duplicate/similar code for I2C/SPI parts. Have a look at the following drivers:
- drivers/iio/accel/mma7455_{core,spi,i2c}.c
- drivers/iio/pressure/st_pressure{core,spi,i2c}.c
- drivers/iio/magnetometer/hmc5843{core,spi,i2c}.c
We want to create a common framework for I2C/SPI parts and reuse it for each driver to avoid code duplication.
Important:
* before starting writing the code send an email to linux-iio list presenting your idea on how do you want to solve this in order to get some feedback.
Resources
linux-iio mailing list.
For questions please send questions in the format mentioned above to daniel.baluta at nxp dot com or the #linux-iio IRC channel (server irc.oftc.net).