Hi,
This post follows a discussion about up-streaming patches to the main kernel tree in the other thread [1].
Koen recommended narrowing the focus of the broad project topic towards certain areas ADC/IIO/PWM etc.
This post is for the project proposal relevant to patchwork needing to be done in the IIO sub-system.
There are several sub-tasks in the project to be done in sequence.
Note: Mostly Koen’s guidance and direction. Some additional notes from my side.
Task 1 :- The IIO driver in the current beagle tree doesn’t create sysfs entries for the TI ADC.
The driver for the AM335x is there [2]. The beagle kernel tree needs a bit of patchwork so that it creates sysfs entries.
Method: Study the ADC(this step needed for future tasks. so do it now). Trace and understand the driver flow.
Study Analog devices drivers. Some of them are well written.
Isolate and trace the sysfs issue in the TI one. Fix it. Test all channels. Patch.
Task 2 :- /dev/iio:deviceX doesn’t seem to work currently
Ask koen/someone for more detail on this one. Is this for all IIO devices. or the TI one only.
Most probably relevant to the TI one. Check and fix.
Task 3 :- Write a small test app to read from the device node and output to console
User space application. Easy. Initialize driver. Read and printf. Have experience with omap_mcspi and spidev.
This should be easy. File I/O. Especially after task 1 and 2.
Task 4 :- Power measurement for the beagle is supported in hardware using a shunt resistor that can be muxed and connected to the AIN7.
Software support is not quite sufficient.
Koen : “Write a hwmon driver that reads AIN7 and sets the correct mux in the PMIC to measure current consumption. using the shunt resistor attached to AIN7”
Studied datasheet and schematic. Beaglebone original has different resistors on AIN7. Beaglebone black has different. Keep various versions in mind while writing driver.
Actual electronics and math behind it is simple application of ohms law.
Just keep the data representations/bias/2’s complement/etc in mind. Depends on ADC format. Shouldn’t be an issue after working on previous tasks.
Task 5 :- The Touchscreen of an LCD requires 4 ADCs. However, there are 3 remaining ADCs as well (Koen mentioned 4 others. I could only see 3. AIN7 is dedicated to the PMIC). People report weird activities on those ADCs. Investigate whats going on and recreate the problem.
Quick google indicated possibly Vref issues and recalibration of LCD required.
The hardware should easily support this as the ADC channels are there. And independent. The common thing is Vref… The touchscreen shouldn’t load the Vref. Not sure.
Past relevant experience that’ll help with the project.
Electrical/Electronics background. Learned Linux myself. Led to embedded linux using beagle-xm and quite some fun on that.
Have experience with interfacing TI AFEs connected to Beagle-XM before. (ADS1298 24 bit 8-Channel via SPI for ECG applications. Using omap_mcspi and SPIDEV.)
Datasheets/Schematics are no issue to read…
lots of userspace programming and driver access.
Some kernel side programming.
Hacked omap_mcspi to initiate spi transaction based on an external GPIO interrupt.
Hacked spidev to use a large contiguous memory mapped buffer that user-space can access.
Technically, I implemented the external trigger and low latency fast I/O buffer features of an IIO driver in the normal SPIDEV/Omap_mcspi drivers.
I understand why IIO subsystem is needed. Especially in interfacing sensors and fast ADCs.
Experience implementing DSP Link on beagle-xm should help too.
Time-line.
weeks 1-4 for Tasks 1,2,3
Week 5 and 6 for Task 4.
Week 7-10 for Task 5.
Weeks 11-12 as a buffer just in case. And documentation etc.
Comments, suggestions, mentors and co-mentors welcome. 
I’ll update this post with a google doc and melange link for the exact GSoC proposal in a while.
Thank-you
ZubairLK
[1] https://groups.google.com/forum/?fromgroups=#!topic/beagleboard-gsoc/dWTiPY-0ntc
[2] http://lxr.free-electrons.com/source/drivers/iio/adc/ti_am335x_adc.c