Differences between revisions 61 and 62
|Deletions are marked like this.||Additions are marked like this.|
|Line 93:||Line 93:|
|* 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.|
Please post all questions to firstname.lastname@example.org. IIO mentors and other applicants will respond on the list and it will serve as a troubleshooting resource for all applicants.
Experimenting with IIO subsystem
Dummy modules compilation
IIO event monitor
Please 'CC email@example.com on all questions related to this so everyone can benefit.
Coding Task 1:
Clean-up idea: IIO Headers: This was previously posted to the firstname.lastname@example.org
See description and follow-ups here: https://groups.google.com/forum/#!topic/outreachy-kernel/LtI90_SwjHE
I believe this task is completed or close to being completed. If you find a driver which you think applies here, be sure to search for it in the outreachy group mailing list to see if it has already been done or disregarded.
Coding Task 2:
The locking scheme in the IIO subsystem includes a lock in the iio_dev structure called mlock. The usage of iio_dev->mlock is being redefined as protecting operating mode changes - as in changes between BUFFER* and DIRECT modes.
Notice how the struct iio_dev fields are labelled [INTERN] or [DRIVER]. The mlock will revert to an [INTERN] field once all the non-conforming usages are removed from drivers. The IIO core functions in (drivers/iio/industrialio-*.c) will be the only users of mlock. Drivers will use helper functions to control operating mode changes.
The piece of the migration this task focuses on is removing the usages of mlock that don't meet the new model. I suspect we'll find that these drivers were using mlock as it was previously defined: "to protect simultaneous device *state* changes." Typically this means they are changing some configuration bits in the hardware. Those changes are important to protect, just do it with a driver private lock, not mlock.
Review this recently submitted patch: staging: iio: ad9832: replace mlock with driver private lock http://marc.info/?l=linux-iio&m=148943215125820&w=2
This is probably the simplest case patch for this task. I want to emphasize simple, because I did pass over a few others on my way to creating an example patch. I saved the more interesting drivers for you
Sign up is on the OutreachyTaskPage
PATCHES need to be sent to all of:
Jonathan Cameron <email@example.com> (maintainer:IIO SUBSYSTEM AND DRIVERS) Hartmut Knaack <firstname.lastname@example.org> (reviewer:IIO SUBSYSTEM AND DRIVERS) Lars-Peter Clausen <email@example.com> (reviewer:IIO SUBSYSTEM AND DRIVERS) Peter Meerwald <firstname.lastname@example.org> (reviewer:IIO SUBSYSTEM AND DRIVERS) email@example.com (open list:IIO SUBSYSTEM AND DRIVERS)
Post questions to firstname.lastname@example.org or the #linux-iio IRC channel (server irc.oftc.net).