Adding Scaled values to the ADC driver within the IIO Subsystem

For the 3.8 tree for BBB, the bone-helper module tries to assist and provide voltage values scaled to 1.8V as limited by the AVDD in the BBB.

However, this is a clumsy hack.
I looked around IIO and other drivers and found that the subsystem supported scaled voltage values. The bone-helper was a workaround to fix the ADC drivers and get scaled values.

I used the IIO Simple driver document to trace and see how scaled values are implemented. And added the required code to the ADC driver.

Preliminary tests show that it runs correctly. :)

Previously there would only be /sys/bus/iio/device/iio:device0/in_voltageX_raw.
Now we see in_voltageX_scale as well :)

I still need to test /dev/iio soon. I haven't touched the adc driver from userspace c applications yet. hopefully they'll work as the sysfs interface works.

I have tried to test the touchscreen with evtest. However, I haven't actually set up the hardware required for it. Connecting ground did register triggers in evtest so I'm hoping it hasn't broken.

I'll look into seeing if I can keep bone-helper so that I don't disturb a bunch of people and capes by this update.
And /dev entries as well..


ZubairLK

p.s.

The patch looks like this.
The last one on
https://github.com/ZubairLK/kernel/tree/3.8-adc-fixes/patches/adc

From 26aa738a0394e39889b4515dde5e2baf99118141 Mon Sep 17 00:00:00 2001
From: ZubairLK <zubairlk@zubairlk-HP-G62-Notebook-PC.(none)>
Date: Sat, 29 Jun 2013 19:05:54 +0100
Subject: [PATCH] Added iio_voltageX_scale

The bone-helper driver tried to display the voltage in the range 1800mV
which represents the actual ADC range of the BBB. This feature is available
in the IIO system. in_voltageX_raw points to unscaled raw values
which give the output of the ADC register directly.

in_voltageX_scale is supposed to give scaled voltages. This was
missing in the TI driver and has been added.
---
 drivers/iio/adc/ti_am335x_adc.c |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index f78d2c1..c030078 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -26,6 +26,7 @@
 #include <linux/of_device.h>
 #include <linux/iio/machine.h>
 #include <linux/iio/driver.h>
+#include <linux/math64.h>

 #include <linux/mfd/ti_am335x_tscadc.h>
 #include <linux/platform_data/ti_am335x_adc.h>
@@ -119,7 +120,8 @@ static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
         chan->type = IIO_VOLTAGE;
         chan->indexed = 1;
         chan->channel = adc_dev->channel_line[i];
-        chan->info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT;
+        chan->info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT
+                                | IIO_CHAN_INFO_SCALE_SEPARATE_BIT;
         chan->datasheet_name = chan_name_ain[chan->channel];
         chan->scan_type.sign = 'u';
         chan->scan_type.realbits = 12;
@@ -189,7 +191,19 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
             *val = read;
         }
     }
-
+       
+        switch (mask){
+            case IIO_CHAN_INFO_RAW : /*Do nothing. Above code works fine.*/
+                   break;       
+            case IIO_CHAN_INFO_SCALE : {
+                    /*12 Bit adc. Scale value for 1800mV AVDD. Ideally
+                    AVDD should come from DT.*/
+                    *val = div_u64( (u64)(*val) * 1800 , 4096);
+                    break;
+            }               
+            default: break;
+        }  
+   
     if (found == false)
         return -EBUSY;
     return IIO_VAL_INT;
--
1.7.9.5

Working with arago patchset

This time I will try to document things properly as I go .

I'm going to forward port the improvements in the arago tree.


After going through all the commits I have to say. Thats a lot of work..

I could just ignore the mfd-next patch and take these changes for BBB 3.8 tree.

However that would defeat the purpose later on. Upstreaming patches and making our tree closer to the mainline. mfd-next is what will be the ADC driver later on. Because those patches have been upstreamed. Like it or not.

So I'll have to layer all these changes on top of that. And then upstream them hopefully..



http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=98260cf92c52e7e4eef3b64b7dcf43d3f14ea969
Registers children TSC and ADC only if available. This change is already incorporated.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=2c67698139cceee19d2205ad34d11c74e758b307
AFE Pen Ctrl and TouchScreen transistors enabling is not

required when only ADC mode is being used, so check for availability of

TSC driver before accessing control register.

Update: Have applied this patch on my 3.8 tree.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=2ce225a521671644ddc4d7b472fac139bb64f9c4
Tries to number channels from 1 instead of 0. Not a particularly useful change.
Also. Driver format has changed quite a bit compared to what I have..

Update: Ignored this one.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=663aa2e74f36a5a8000224b37a74c11ee729550d
Important Patch.
Message "Previously we tried to read data form ADC even before ADC sequencer finished sampling. This led to wrong samples.  We now wait on ADC status register idle bit to be set."

Update: have applied this patch to the 3.8 tree. Led to the correction of the first sample.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=09597d7a244a8e6f5ea79da3c5dced3a5ea620c4
Important. Sets the ground for interrupt handling on the TSC side.
At the moment IRQ is taken only by TSC. This starts changes to shared structure.

"Touchscreen and ADC share the same IRQ line from parent MFD core. Previously only Touchscreen was interrupt based. With continuous mode support added in ADC driver, now driver requires interrupt to process the ADC samples, so enable shared IRQ flag bit for touchscreen."

Update: Have applied this patch to the 3.8 tree.


Update: We(Me, Koen, Greg KH) decided to freeze development on the 3.8 tree and move to 3.11.

I have added another fix which removes the need for bone-helper. The 3.8 tree had the bone-helper driver to help with ADC detection and scale values to 1.8v.
There were bugs in the underlying driver as well which caused erroneous values and the need to sample twice.

The ADC driver for the 3.8 tree will hopefully be replaced by this new patchset I have soon. I am still testing and refining the patchset.
But I have successfully scaled the voltage values within the IIO subsystem model. And fixed the need for sampling twice. The tests I have run yet are simple connecting the adc to ground or 1.8v or 1.5v. And checking via sysfs.
The more thorough test for /dev/iio via a userspace application is needed.
And the interaction between the touchscreen and ADC drivers is to be tested and seen if it works.

The patches below and the ones above will be applied to the 3.11 tree after re-basing the ones from mfd-next by Sebastian as well.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=b332370651a7d64d3c6ed8780d939fc18163e141
Most important patch I guess. Adds continuous mode and IRQ.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=478af139295b451c59eeba8f851654964321cbfe
Imp "ADC reports few wrong/erroneous data on read in continuous mode. Providing an appropriate delay so that ADC has sufficient time to sequence data present on the input channel. "

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=585b034972eb667cce3bf9f3bc5bb46f1f21bced
Imp. "The ADC driver did not check for FIFO1 underflow and overrun conditions. Add support to handle these conditions. TSC/ADC module does not recover from this state by itself, a module reset is required."

The driver has diverged a lot from what is in mfd-next. Poll handler. Irq. continuous mode.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=b9a063a1654653348161de8d3d411d8ce2f56856
not implemented.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=adb9fa13a403f0f6f4e0d57a0bfcfd1a91e0edea
not implemented

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=1be244a840f9a162e3c832d7c1686100a6096a7c
not implemented

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=333f3460f855abd02c7e7eefcb692740ecd9c662
Simple one. Can be applied easily. Clock 3MHz check.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a62dbd7027667d99254f0f38f9364e4edcd56ddc
Seems similar to what is there. But error handling corrections.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=0f2a3e7288e91d42f9a527f193b1df61d5afff5c
FIFO 0 for tsc only. not implemented. quite different structure..

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=2e8d35ab98789ee8b0d0d56c2a5d72940ffb2670
Not implemented. Quite different.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=2ab9b41a1ac235c81f20bfebec69d4eb7021b275
Very different structure. Some TSC fifo issue.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=931e7f0032c5113f82f7b59b29406d2e9eab1c48
Step enable bits etc. Not implemented for continuous mode.

Russ dills bugfixes from now onwards. These are small bug fixes.
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=7ce1a9f88aea036034e5e7dc65480694e7e0913d
IRQ stuff again.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=8607406b53cc6bd65cd48ed17d34ae2455271aa2
IRQ stuff

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=7fb9db4270711a434a8dd322ad1e3a6e7f798b91
IRQ stuff

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=bd967ca8af48bd56076fad77ac77a010f3efd21c
IRQ Stuff

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=da42b4c279d6241cab87bff5ea6d83c02651ef7e
IRQ Stuff

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=7295475758e73aa72a92cdc720186698cec8d033
FIFO clear on next work.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=de871da92081b17d6f286b5774ce24a938065f0b
Some error handling

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=2404a847db796cd17a9189d7ac2b73fe22446ebf
Some fifo check.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=337c3895437961b85bf507cfe2e2847a7851b4f2
tiny Fix


http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a819c4feafe9eac8d2e756954ab4e111c5b83732
Reverses a previous commit for delay that is not needed.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=18ce4a630452348b8308b922491130e8ce1e9134
Some power stuff. small.

Working with a patchset upstreamed via mfd-next

Ok. So I started from scratch on the ADC drivers.

My current aims are to start from 0 ADC patches in the 3.8 tree we have.

Then go up to the patches in mfd-next which incorporate a number of changes.
https://lkml.org/lkml/2013/6/12/371

But I couldn't just apply those patches directly could I. Tweaks and changes were needed.

List of changes.

Subject: [PATCH 05/21] input: ti_am33x_tsc: Add DT support
Guy missed out two steps to configure change to coordinate readout. But he removes the function later on so his tree doesn't break..
I wanted to keep that function later.

Did not apply number 6,8,11,14 which removes platfrom data support
Did not apply 15 and 16 which only renames DT bindings. But that would be unwise as it would mean changing DT patches.

Tweaked 9 as the patch changed the name to am3359 in places. Keeping it tsadc would be wise as that would keep DT unaffected.
Tweaked 20 a bit.

After a debugging session, I found out that IIO had improved from 3.8 to mfd-next. So those improvements had to be backported.
One was a bitmask. The other was interesting. While getting DT from childs a function would be called again in sub-functions. The data structure was tweaked to not require this. But I went back to calling the function twice instead.

IIO improvement backported. tscadc_dev->dev->of_node is being used in the 3.8 IIO. Not pdev->dev_of_node. which

Also. IIO was restructured a bit. A
node = of_get_child_by_name(pdev->dev.of_node, "adc"); was added in adc probe.

"EDIT. Dont make this mistake again. Be extra vigilant. Or you'll be debugging oops errors forever..

+        node = of_get_child_by_name(node, "adc");

And watch oops errors. They may have changed while you assume you are getting the same error.."

 Basically this function was called twice in 3.8. Till mfd-next (3.10 i think) the data structure had changed. Such that the nested call already had the ds and didn't need

12,17,18,19,20 caused hunk fix problems. git am wouldn't like them
So I used patch then diff to correct stuff.

Because of all my work in the ADC patches. There was one minor inconvenience in the other patches in the tree.
 the surrounding code had changed for a patch that was adding to the DT.
So I tweaked the DT stuff a bit as well.

patches/da8xx-fb/0022-ARM-dts-AM33XX-Add-am335x-evm-lcdc-panel-timings.patch:18:
was ti,adc-channels = <8>;
now
ti,adc-channels = <4 5 6 7>;

Channel access had changed. So I had to change DT stuff slightly to the above in our relevant BB patches too.


Now for debugging the ADC more and the arago improvements. which are much more in number! And much better for ADC!

But I guess if I layer patches on top of this I could easily re-base them for upstreaming. Yea :)

ZubairLK

Brick + Recovery + TFTP

Managed to brick my BBB within two days of receiving it.
Fix up the eMMC using http://www.crashcourse.ca/wiki/index.php/BBB_software_update_process.

The trickiest part was that I didn't realize that the script was working in the background and I just had to wait. I thought I'd see messages pop up on the serial console but nothing came up. And wasted a day thinking why isnt it working. vvu on #beagle-gsoc told me to simply wait. Lol.

A simple ps -a cleared the matter :) 

I wanted to set up uboot so that my uImage boots via tftp.

Lots of guides here and there. http://eewiki.net/display/linuxonarm/BeagleBone+Black and http://wiki.beyondlogic.org/index.php/BeagleBoneBlack_Building_Kernel

A bit scattered though. And 3.8 kernel changes quite a few things.

http://elinux.org/BeagleBone_and_the_3.8_Kernel is a comprehensive overview of changes.

Anyways. My uEnv if anyone interested.

"
optargs=quiet drm.debug=7

ipaddr=192.168.0.250
serverip=192.168.0.1
#run tftpboot 0x80200000 uImage
#uenvcmd=run loaduimage run loadfdt run mmcargs bootz 0x802800000 - 0x80F80000

bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

uenvcmd=echo "Booting from Network";tftpboot 0x80200000 uImage; tftpboot 0x815f0000 dtb; bootm 0x80200000 - 0x815f0000
"


One thing to note that someone helped me out in IRC.
3.8 is a DT based kernel. So its not just the uImage file to load.

If you are loading just a uImage file. Then you have to load the uImage-dtb file which can be compiled. Which is basically the DT appended to the kernel.

Otherwise you can load two files. uImage + DT. The DT file is the device tree that replaced the old board file system. It took a while to digest things.

https://www.youtube.com/watch?v=MOhVdknBOkw Links to a presentation by Koen on it as well.

ZubairLK

Beaglebone first steps

The beaglebone black is here. Its much easier to get up and running than the XM.

Just connect the usb cable. More info here
http://beagleboard.org/Getting%20Started

I wanted to access internet on it. This can be done via the usb cable itself. No need to connect ethernet even! Magic :)

http://travis-lab.blogspot.co.uk/2012/02/getting-on-beaglebone-on-internet-using.html

Add a sudo for ubuntu. And check the comments for an additional step for ubuntu as well.

Then I like some vnc every once in a while. So follow
http://digitaldiner.blogspot.co.uk/2013/05/quick-hint-for-beaglebone-black-user.html

Voila!

Now for some kernel hacking magic!

I've noticed some stuff. The helper script is the way to access the ADC.

http://hipstercircuits.com/reading-analog-adc-values-on-beaglebone-black/

That isn't cool and has to be patched immediately! I'm looking into it.

Zubair

Thoughts on ADC patches floating around the globe

I'll hopefully get my hands on the beagle tomorrow. Until then, I'm pondering and over thinking about the ADC drivers, kernel trees and patches.

In retrospect, I think it actually helped that I'm mulling over the kernel etc for such a long duration. I have learned a lot and read around alot instead of playing with the beagle!

The GSoC application proposal i submitted gave me the first three weeks to set up a dev host (done), recreate the problem with adc drivers, patch the adc drivers.
An additional goal later on was to forward port driver improvements from the TI Arago tree which is based on 3.2 http://arago-project.org/git/projects/?p=linux-am33x.git;a=summary.

Instead of finding problems and fixing them, I am thinking I should directly jump ahead and forward port all improvements of the 3.2 tree.

I could write code myself. But I think that'll take a significantly larger amount of time. The work is done and out there in patches here and there. Its just scattered.

I have browsed around a lot and found three places where useful patches exist.

1. One kernel/3.8 branch koen is maintaining. https://github.com/beagleboard/kernel/tree/3.8

2. Linux next just received a patchset https://lkml.org/lkml/2013/6/12/361

3. Arago tree. (link earlier above)

The lkml work is recent and is a mixture of various previous patches from the arago tree and some of the authors own work.

But to be honest, I'm inclined towards the Arago tree for completely stable work. At the moment, I intend to take the 3.8 tree by Koen. Remove the ADC patchset existing at the moment. Which will bring the ADC files to a blank point where the 3.8.13 stable kernel is. I traced the same point in the 3.2 Arago tree. Which is pretty far behind. Then go through all the changes one by one. Generating a patchset.
Then I'll go over Koen's existing patchset. And see if there is any improvement in that which can be added as well. Then go over the recent lkml list patchset and see if there is an improvement there.

Edit: This is called rebasing! Just occurred to me from a comment by Patil Rachna on a patchset and Googled around to confirm. I guess Greg could work up some git magic to do all this :). But where would my GSoC work come :P

Edit again. It isn't exactly rebasing. The gap between the kernels is huge.

I don't know how big a task this is. I'll get started this weekend.
I'll know how big a task this is by actually starting and doing it.

Cheers
Zubair

Update. ADC + Touchscreen interaction

Hi,

IRC meeting on #beagle-gsoc went well. Just some introductions. And I asked a question to which I should've known the answer.

Anyways. I was confused about the interaction of the drivers of the 8-channel ADC and the touchscreen input driver. I had missed a file which was the actual ADC driver. I was only looking at the ADC IIO file and the touchscreen input driver files. Both the ADC IIO and the touchscreen use the same ADC source file which is found in a different folder. I missed that and [Russ] pointed it out to me I think.

I should have noticed the common header..

Links below are for the mainline kernel..

For the IIO driver, you find it in drivers/iio/adc/ti_am335x_adc.c
For the touchscreen driver you find it in drivers/input/touchscreen/ti_am335x_tsc.c
For the base file both use, I found it in drivers/mfd/ti_am335x_tscadc.c

Depending on the kernel tree you browse. You might find some of these files in the staging folder. (staging folder is the place where linux kernel developers put drivers and stuff that isn't fully refined enough to be incorporated in the main master branch)

At the moment I am going through stuff in the Useful links post.
I'm playing around git. Its a really powerful tool with an equally steep learning curve.

My beaglebone black should be on its way.

http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver%27s_Guide has a really great overview of the ADC and touchscreen driver and how to get them to work.

Greg KH (my mentor for the project and a great guy) has a repository with some great tutorials https://github.com/gregkh on kernel development.


I have gone through the tutorial. Now, I will play around and get my head ok with the beagleboard kernel patches repository https://github.com/beagleboard/kernel maintained by Koen (co-mentor for the project and another great guy).

I have a feeling that a significant part of my work will be forward porting the developments of the ADC driver in the 3.2 kernel tree by TI to the 3.8 kernel tree for the beaglebone. This done correctly should cover quite a few mile-stones of the GSoC project I proposed.

I will have a 3.8 mainline kernel tree patched using the beagleboard repository.
And I will have a clone of the kernel tree maintained by TI.

Maneuvering through the repositories using git is going to have a steep learning curve. But I'm starting to get a handle on things.

GSoC 2013 officially starts on MONDAY!

Cheers
Zubair