Beagle GSoC13' Project: IIO -> ADC -> PMIC -> LCD debug/fix/patchwork


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.

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. :slight_smile:

I’ll update this post with a google doc and melange link for the exact GSoC proposal in a while.



I would like to help mentor this task as well…



Thank-you very much! :slight_smile:

Any suggestions/directions regarding the work? Is it too ambitious?

Also, I’m a bit unsure about the context of the /dev/iio:deviceX not working part…



I’ve started formalizing the proposal a bit.

The main concerns is:

I need feedback from community members (at least one mentor) regarding the patchwork on the ADC IIO driver.

Could someone please take some time and provide some feedback for the GSoC application.
Thank-you. The first post is enough to give you the gist.

The google doc below is the GSoC application of the same.


Sorry. I moved away from the other thread and shifted here as I realized the projects focus narrowed down.

Also, I’m still awaiting feedback from community members regarding this project for the GSoC application.

Quick summary. ADC IIO drivers are slightly broken (sysfs and /dev/iio:deviceX not working properly)
For this project, I patch those and then I build up drivers for PMIC AIN7 measurement.
Then, I check that the LCD Touchscreen driver doesn’t clash with the rest of the free ADC channels…

Any comments will be welcome.



The google melange application is much more refined.

Here is the link

Comments, mentors, co-mentors, suggestions welcome…