Success at last :)

Finally. Patches for continuous sampling got accepted in IIO.

http://thread.gmane.org/gmane.linux.kernel.input/32024

All the hard work paid of in the end. Achievement unlocked.
:)

A hiccup n warning here n there mentioned by the autobuild scripts. but no biggy. sending a couple of cleanup patches in a jiffy

http://thread.gmane.org/gmane.linux.kernel.iio/9638

Now for rebasing stuff for koen's trees. A long blogpost describing how to get the driver to work from userspace. The trigger stuff on the blog is redundant and misleading now. I'll put a note in the start of those posts pointing to the new one when its done..

Round 11. 2 steps forward. 1 step backward

The devm usage initially guided by iio was incorrect as pointed out by Dmitry.

reverted the change. Go forward. Go backward. But like Koen pointed out once. Any feedback is good feedback. MIA is the worst. So i should remain thankful :)


And on another note,
fifo storage was 32 bit. But actual adc data was 16 bit.
iio didn't like it. Changed it. memory usage is a bit optimized now.

http://thread.gmane.org/gmane.linux.kernel.input/32024

And the hope/wait begins

Finally. So close yet so far.

IIO likes the driver except for one tiny bit.
Using a 32 bit buffer to store 12 bit adc data.

Except for that minor change jonathan stated 'Very very nearly there' :)

I'll make the changes and test the thing and get it done in some time

Thankfully, i'll be walking away with a completeness feeling from GSoC :)

Round 10. quick update

I misunderstood the new devm interfaces.
Dmitry and Jonathan were kind and explained it to me.

I updated and resent the series.

http://thread.gmane.org/gmane.linux.kernel.input/31993

Round 9! Continuous Sampling support

Finally put another couple of rounds of energy into the IIO driver..

It should get accepted now. *hopefully*

3.12-rc1 has started!

any ways.

I have restructured the driver the way Jonathan wanted. *again*!

I sincerely hope there isn't any big structural issue now.
Small fixes/rebase is ok.

http://thread.gmane.org/gmane.linux.kernel.iio/9438

Fingers crossed..

I need to rebase stuff for Koen's trees too..

Rework. Again.

This is getting quirky.

http://thread.gmane.org/gmane.linux.kernel.input/31730

Feedback from IIO thankfully. Now I don't have to sit idle.

But I'm in new territory now.
basically IIO wanted me to implement a trigger based continuous sampling where the iio trigger occurred on every fifo threshold interrupt.
I implemented it.

But after seeing it. Now they want something else instead :)

And that is tricky and new territory.
Up till now. IIO relies on existing drivers as a template for people like me who have to write another driver.

However. there is no existing driver that I can use. Because the am335x has a hardware fifo. and IIO drivers for adc's are mostly for external adcs and one-shot. Even if continuous. They use external triggers for sampling. Kind of like a continuous one-shot.

But for the am335x. As an ADC i'd say its better! But doesn't fit existing IIO models. Especially the internal triggerless sampling based on the ADC clock and fifos.
One would think a fifo and adc sampling is simple. It is. But the firmware is a pain. And fitting it in the IIO model/ABI is even more of a pain.

IIO has support for this. But no existing driver that uses it.
I would look at existing drivers for help every time.
Now i have to look deeper inside the IIO core and get things to work..

Apart from the fact that there might be unknown issues in the core itself as its basically untested I guess..

stumbling blocks

Exchanged an email with Jonathan..
I missed the window for submitting the patches for 3.12. He said that they'll go for 3.13 now.

I don't think they'll be reviewing the patches during the merge window..

I guess I'll rebase the work and push it to the trees koen maintains. and write a few blogposts on the new interface for the continuous sampling.

Not exactly sure what to do now lol. this patches stuff got delayed by two weeks that the merge window will last. I'll have to push on these patches after gsoc timelines perhaps.

Round 7! continuous mode

This is getting really tiring now.
Send patches. wait for feedback that messes with your head.
Do it all over again. No wonder the world works on automated test scripts etc.
my testing is slow i think. other than that. updates using git rebase are getting really good.

*LOL*
I didn't check the iio branch and found that it had gone ahead by dozens of commits..

had to check right after sending the mails for round 7 lol..

Anyways. hope they dont mind the spam. sent round 8 immediately with updates. thats why they use scripts. some of em probably check if remote branch has gone ahead or not..

http://thread.gmane.org/gmane.linux.kernel.input/31730

Anyways. i think i missed the time window and the patches are going to be rebased and sent etc etc after 3.12..

Lets see what Jonathan has to say about them..

Round 6 list feedback

Some serious stuff going on the lists.. The Linux Kernel really is scrutinized awesomely.

http://thread.gmane.org/gmane.linux.kernel.iio/8861

Highlights:
- Quirks in error handling paths for freeing the device due to devm_iio_alloc
- error handling technique for trigger alloc in the probe. should be in trigger alloc function.
- missing lines for removing trigger in remove function.
- TSC/ADC IRQ sharing is confusing and messed up. Explanations.
Missing entry in Kconfig.

Refix and resend. And then the wait begins again.
Although, the main guy reviewing Sebastian is leaving for 3 weeks.. Hope Jonathan gives the driver time and accepts it for the next cycle.

Round 6. Continuous mode the way iio wants

IIO didn't like my usage of their trigger oscilloscope style. Messed their ABI.
Soo. there is an internal trigger in the driver that occurs for every threshold.

After the changes and some cleanup.

I'm back online with round 6. hope iio likes the driver this time.

http://thread.gmane.org/gmane.linux.kernel.iio/8861

Major changes in the way driver works.

Previously i would use a sysfs trigger to trigger the start of sampling after enabling the buffer.

IIO didn't like that. And suggested that I create a driver trigger that would automatically trigger upon the FIFO threshold being reached every time.

So. I did that. It took a while to restructure the driver.

I do note one thing. Previously I would get the illusion that the adc driver is working alongside the touchscreen events.
I think I was wrong. I looked at the code, thought, and checked the irq status again and again. Only one side is active at one instant.

Which makes sense sorta. Cause the way I understand the hardware. The SW steps can happen (adc) or the HW steps can happen (TSC). So one of em has to give in.

Although, at the moment, the ADC is at max sampling frequency. Perhaps configuring the adc with a slower sampling rate might allow the TSC steps to be configured. I'm not going deep into the sampling frequency yet. it has to do with the step delay register. the way i see it. i think all the channels can have individual sampling frequencies as well.

IIO was designed with loads of flexibility in mind. but i think it was made with external adc chips in mind. not internal powerful adcs like this am335x one.

IIO list feedback Update + Short Hiatus

Feedback from the IIO lists has been great.

https://lkml.org/lkml/2013/8/13/553

and

https://lkml.org/lkml/2013/8/13/666

I use the IIO ABI in a slightly non-standard way to get things done.
The trigger in IIO is for triggering a single sample of data. I guess its for ADCs using the DRDY style signals etc. Thats not useful for me to to have continuous sampling.

I used trigger to start the trigger oscilloscope style. To trigger a large buffer of samples.

Jonathan actually suggested that such a feature could be great in the IIO core and was open to a proposal for it. Even gave a couple of paragraphs for the interface.


Given the nature of the am335x sampling and fifos, the IIO trigger model doesn't fit well to trigger every sample in continuous sampling mode.

Jonathan suggested to use internal triggers that occurred every time the FIFO thres handler is called. Just so that the driver fits IIO ABI a bit more/closer.

I don't see any problems with implementing the driver the way IIO wants.

But I'm taking a short break to finalize my MSc. thesis report this week.

GregKH is great and cool with it.

Round 4

More patchesssss

Small fix to MFD here
http://thread.gmane.org/gmane.linux.kernel/1543722

TSC fixes and Continuous mode here.
http://thread.gmane.org/gmane.linux.kernel.input/31427

I left out a fix for rc1 of the new one. Because I sent around various patches sporadically. One fix in iio. One fix in mfd.

I cant send the last fix because if plays around with everywhere.

But no issues.

And fixes

lots of tiny fixes here n there

It turned into a chain of fixes. I'd fix one and then find another in the process.
Fixes would become bugs and then fixes for that lol ;)

Lets see.

HW preempt enabled.
Before, ADC was given priority. Not TSC. TSC event couldn't mess with ADC sampling. By enabling HW pre-emption, TSC event is given priority. This was done in an attempt to fix the TSC not registering a pen UP event even if the finger was lifted. (during ADC continuous mode sampling in the background)

There is a small delay in the TSC IRQ which lets the TSC sequencer settle before checking for pen UP events. Had to increase that delay slightly to allow a pen UP to be registered.

Locks in mfd.
One fix is already in the staging. And I forgot that the function comes in pairs. I sent a fix for the set function. But forgot the clr function lol. While fixing the continuous mode driver, i found the need for the clr function and realized that the fix is mising here..

TSC steps enable issue
TSC steps would disable if I mess with the ADC. Because the ADC would also play with the step enable register. the common mfd core locks for set/clr help. But not completely.
In some cases (during the reg_SE read, update, write, some bit would go bad), the TSC steps wouldn't be enabled properly. And that would caused the wrong configuration to hang. So had to add a mask to the mfd core.

TSCADC disable in ADC code.
The continuous mode code was littered in dozens of places with areas that would enable/disable the entire module. I think this was the real culprit causing the entire thing to hang. Put checks around to not disable the entire module if the TSC is alive.


Reg_SE written with 0x00 on ADC side.
Previously, channels for continuous sampling would enable and disable in iio_trigger_preenable. That would mess step enb register. There was even a write 0x00 for the SE register in there.
Now they update the SE register via the common mfd core.

I guess I was looking only at the ADC before and I didn't realize.
During the bug fix phase, I'm looking at both TSC and ADC and making sure they work.

Now I have a working continuous mode with TSC events that can occur simultaneously and TSC doesn't hang.

But I have a different issue lol. Asking greg about it.
Fix in mfd tree.
Fix in iio tree.
My patch series depends on both trees. lol.
and splitting them can be tricky.

lets see. greg said something about split. most of em can be split except for one fix which can go later.
lets see.

have to sort out the code and send it to the subsystems.

BUGGGGGGGGS

I have noticed three(lol. Update. 6 now) bugs in the TSC ADC driver.

Subtle ones. Quite possible won't occur in use cases at all.

Bug 1. (resolved)

When I am waiting for a trigger, the touchscreen stops working..

This one is cause the following line on the ADC side disables the TSC steps.

 tiadc_writel(adc_dev, REG_SE, 0x00);

the tsc is ok after trigger.
But if i do an event during waiting for trigger.
tsc works. but adc doesnt. meaning tsc is disabling all configuration i did for continuous mode!

Managed to move around the bit masks to the poll handler function.
This one is ok.

Heard back from iio list with some comments.
I'll resend the patches with this bug fix squashed in.

Bug 2. (sudo resolved)

If I do a
while(true)
do
cat in_voltage*
done

to continuously read samples using one-shot adc mode.

The touchscreen registers clicks randomly!!

Although this is a wild test case, it shouldn't happen

Update: 
This is weird. Shouldn't waste time on this bug.

while (true)
do
cat in_voltage4_raw;
cat in_voltage5_raw;
cat in_voltage6_raw;
cat in_voltage7_raw;
done

wouldn't make the tsc register events or go haywire.

but

while (true)
do
cat in*;
done

would register events on TSC. Strange. I quadruple checked all the ADC reg configs even! everything is ok. The TSC shouldn't receive interrupts.

What happens is that HW steps which aren't supposed to run unless a touch is registered actually do seem to run 'once'.
This fills FIFO0 which threshold interrupts.

Thus, a random click and PEN UP somewhere. Uncool.
But anyways. Seems random. Especially since the expanded while loop didn't register the same phenomena.

Useless. No more time wasting on this bug. managed to catch another unknown one during this process lol. bug 4!.

I have to say. The more bugs I encounter. The more I understand the driver and TSADC module. The more I realize I know nothing!

Bug 3. (left for later)

This one is even more subtle.
The old 3.8 touchscreen driver was very smooth and registered clicks properly.
The one after sebastians patches seems as if the mouse is going slightly haywire sometimes.
Sometimes click takes the mouse somewhere random. This is a really subtle one.

I'll spend time on this if I get the chance. My focus is more ADC. But obviously. Community is community. And I'm in a good position to fix this.
Basically have to compare the previous driver and the one after sebastians patches in mainline. Somewhere some calculation(i guess) is different. Although sebastians work is based  on the same arago. But something feels off..

Bug 4. (Resolved. Patch upstreamed :) )

This time its the MFD driver. the MFD driver has a small function to update the Step enable register.
Problem is. It used a reg_cache. Which isn't updated anywhere. So if I use a TSC and ADC. The reg_cache gets loaded with FFFF and all steps are enabled no matter what. ADC steps disable themselves after one sample. Which makes it ok.
But sorta. The FIFO1 still gets filled up with samples.
 
The current read_raw code was ok in the sense that it flushed the entire fifo.
But too many TSC touches and the ADC FIFO will fill up with useless samples. That'll make a mess most probably.
So yea. good thing I caught this bug. I'll send it as a fix to the MFD list..

(OOO. Just realized. Steps updation might be why continuous Bug 6 isn't working. Damn. I'll have to check again..) (Update again lol. Dimitry from input pointed out as well. IRQs might be hanging..)

Fix was simplish.
added a read in there which checks current steps.

Bug 5 (Resolved!)
This is a fine example of a bug you add for no reason and then have to fix!

I was aiming to optimize the read_raw function. But indirectly added some redundant samples that wouldn't flush. This would make a mess.

If I read channel 5, I'd return early thinking I was efficient. Didn't realize Channel 6 and 7 would be in FIFO and those needed flushing.

So if i read channel 7 after 10 sec. I'll get the old value. And more old data would be in the fifo. "Unoptimized the bug again". I'll squash this fix in the next series I send to IIO.

Although I personally don't like the idea of sampling all channels and then flushing them out. the continuous mode code can be used to enable one channel only. Its a simple mask.

But alas. I'll see if i want to clean up things. it works as it is anyways..

Bug 6 (WIP)
I dont know if this is a viable test case or not.
A simple delay in a userspace application might make this go away. But yes. its bad.

While waiting for trigger.

If i'm pressing down on TSC,

and trigger the adc.

The entire TSCADC module hangs. Nothing works.

I think the IRQs hang somehow. Cause cat /proc/interrupts stops registering anything.

Maybe both handlers return none or something. And the IRQs of the TSCADC module don't occur again.
Tried moving around stuff to end. But didn't work.
Added ovverun handling but nope.

Russ tried pointing it out on a patch. But Greg said level interrupts are ok.

(Update, Dimitry from the input list pointed out the same for the patch I sent. What will happen if both IRQs go off.. Thats why system hangs maybe..)

I guess this might be something really quirky.
Its an awful usecase anyways..

Maybe both overrun and stop the TSCADC module. and the IRQ handlers don't go into ovverun. This is quirky to debug.

If I'm making a GUI running on TSC acquiring samples. I'll add a delay between the button press and the ADC sampling to avoid this race condition.

But yea. something like a GUI oscilloscope on a BBB might seem far of. I don't think the module can handle such complexity for real time sampling and display.
But sorta periodic trigger buffer sampling display might work. Anyways.
Oscilloscope on BBB might be a fun idea but I need to work on the GSoC project for now!

Triggering the IIO ADC driver using a GPIO survey

In continuous mode, the ADC driver can be triggered using a GPIO.

(For details on continuous mode: http://beagleboard-gsoc13.blogspot.co.uk/2013/07/sampling-analogue-signals-using-adc-on.html)

GPIO numbering on the BBB can be a bit tricky due to the multiple banks.
If you don't know what I'm talking about, see
http://www.armhf.com/index.php/using-beaglebone-black-gpios/

Now that we know which GPIO to use for triggering your ADC, we try to look at how to connect the gpio to the IIO driver.

As usual, the IIO subsystem is cryptic. Diving deep into IIO code is very tricky. I'm not that good yet I guess.

I've asked on the iio list. Could be something really simple i'm missing..
Have tried googling for a couple of hours.

Sampling analogue signals using the ADC on the Beaglebone Black

NOTE: THIS CODE IS OLD. TRIGGER HAS NOT BEEN IMPLEMENTED IN THE IIO DRIVER ANYMORE. FOR RUNNING THE LATEST IIO DRIVER, you have to modify generic_buffer.c and remove trigger checks.
06-Jun-2014



7 channels of the ADC are available on the expansion port of the Beaglebone Black. Accessing them can seem like a daunting task at first but it is quite simple once you get the hang of it.

The kernel that ships with the BBB as of 27 July doesn't support the stuff below. So compile one from the latest sources available at 
https://github.com/beagleboard/kernel/tree/3.8.

If you don't know how to compile the latest kernel sources, check the following links for help on how to compile the kernel.

http://beagleboard.org/linux

http://wiki.beyondlogic.org/index.php/BeagleBoneBlack_Building_Kernel#Compiling_the_BeagleBone_Black_Kernel_2

http://eewiki.net/display/linuxonarm/BeagleBone+Black


After booting the BBB, you have to configure the ADC pins and enable the Touchscreen/ADC (TSADC) module in the processor. This is done via the device tree(DT) files.

DT is a standard format since kernel 3.8 that tells the kernel what it needs to do to enable the TSADC module and configure the ADC pins.

Thanks to the great people at BB.org, you only need to do this

    echo BB-ADC > /sys/devices/bone_capemgr.*/slots

Check that it loaded correctly using dmesg
You can also list the current configured peripherals using

    cat /sys/devices/bone_capemgr.*/slots

Now checking the analogue value at one instant is simple
All you need to do is type the following

    cat /sys/bus/iio/iio:deviceX/in_voltageY_raw

where X is your adc device number and usually 0.
And Y is your analogue channel number.

Some people might be happy with one sample every once in a while in their applications.

However, the ADC is capable of much more. If you need to sample a signal continuously via a C/C++ application from the userspace, you are in luck.

The am335x driver is a standard IIO driver. And the IIO subsystem provides a sample test application to test the driver. Or in our case, to read from the driver.

The test application can be found in your kernel sources in the drivers/staging/iio/Documentation directory titled generic_buffer.c

Or if you want to take the easy route, check the following link for sources.

https://github.com/ZubairLK/adc-iio-continuous-sampling-userspace

There are two parts to continuous sampling.
Configuring the ADC and the buffer.
Triggering the driver to tell it when to start filling in the buffer.

The IIO subsystem supports a trigger mechanism which is separate from the main ADC driver. The ADC driver supports any standard IIO trigger. And IIO provides trigger files which enable triggering via GPIOs or sysfs files.

Here I'll explain the sysfs way of doing things.

To add a sysfs trigger file type the following

    echo 1 > /sys/bus/iio/iio_sysfs_trigger/add_trigger

this creates a trigger directory in

    /sys/bus/iio/trigger0

Note: If you dont see this directory. You don't have a supported kernel. Compile the one using the latest sources.


Running the following pulses the trigger.

    echo 1 > /sys/bus/iio/trigger0/trigger_now

 
The trigger alone is useless. We need to connect this trigger to the adc driver.

Compile generic_buffer.c from the above github repo.

Then run the file using the following parameters

    ./generic_buffer -n TI-am335x-adc -t sysfstrig1 -l 128

 
The application searches for an IIO driver named 'TI-am335x-adc'.
Connects the trigger named "sysfstrig1" to the driver.
And configures the buffer size for 128 samples.

You might have noticed that you haven't exactly specified which channel you wish to sample. That is enabled separately via sysfs.

All this might seem confusing at first. But the IIO subsystem is designed to be highly configurable and adaptable to accommodate a variety of peripherals such as accelerometers, gyros, adcs etc.

Enabling which channel to sample using the triggered buffer mechanism is as simple as

    echo 1 > /sys/bus/iio/iio:deviceX/scan_elements/in_voltageX_en 


Where X is the channel number.

If you wish to enable another channel. Go ahead. The generic_buffer application will list both channels. Just note that the buffer is common for both channels.

e.g. 128 will result in 64 samples of 2 channels.

generic_buffer.c is just a starting point for your userspace application.
To sum up, you need to run the following to read continuously from the ADC.

    echo 1 > /sys/bus/iio/devices/iio_sysfs_trigger/add_trigger

    echo 1 > /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage7_en

    echo 1 > /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage5_en

    /home/root/main -n TI-am335x-adc -t sysfstrig1 -l 128 

And then run this in another terminal to trigger the driver to start sampling

    echo 1 > /sys/bus/iio/trigger0/trigger_now 

The generic_buffer application will display the length of samples.

Enjoy hacking with the BBB.
Leave a comment if you have a question or notice a bug somewhere.

Fixes accepted and upstreamed. Continuous mode Upstream effort Round 3

The fixes I sent upstream were accepted! :)

So now the adc driver will have correct one-shot adc reading since 3.11-rc3.

Greg KH has a way with patches. This space is wrong. Fix.
And he'll stop reviewing the thing! lol.

Thankfully I'm getting comfortable with git rebase.
Fix and resend.

GregKH This indent is wrong. Fix.
Fix and resend.

A dozen exchanges like this came the much awaited.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
And then
Signed-off-by: Russ Dill <russ.dill@ti.com>

Finally!

I have sent the patch upstream
http://thread.gmane.org/gmane.linux.kernel.input/31272

Lets see what IIO has to say about it. I'm kinda happy with the driver now. It wasn't good previously.
The only intricate thing in my mind is the way I used IIO triggers.
Triggers are meant to be used for acquiring one sample. I used the iio trigger to acquire a buffer of samples. Who knows. Maybe they aren't solely for acquiring one sample and its my misjudgment. I couldn't find from the wikis..

Lets see

ZubairLK

Upstream effort 2

After greg kh pointed out some really newbie mistakes, I redid the patches.

1 - messed up authorship. patches seemed as if I authored them.

Corrected with. git commit --author "orig author

2- code formatting issues were handled at the end by 3 patches.
totally non-standard practice. each patch has to have correct formatting.
redid the entire series.

Also, squashed some patches together.
Learned git rebase in the process which is really powerfulllllll.

I resubmitted the patch series

http://thread.gmane.org/gmane.linux.kernel/1527809

Feedback has been cool. Jonathan(King of IIO) pointed out that part of the patch series is a fix. The ones that fixed the first sample read issue by adding a timeout in sampling.

He wanted to separate the patch series into fix and feature..

I just did the fix part. http://thread.gmane.org/gmane.linux.kernel.iio/8326

Now. The feature part is tricky. While working on continuous mode, I realized that its one big patch. Then a number of bug fixes. Whats the point. I did squash some bug fixes in the big patch. but left out some bug fixes too..
to maintain git history.

Jonathan  asked to squash the rest of the bug fixes in too.. Lars-Peter acked that as well.

It'll basically reduce the patch series to around 3 i think.
1 for tsc tweaks related to shared irq.
1 for mfd tweaks maybe.
1 big one for the adc driver.
n voila.

Jonathan also pointed out that the show mode and set mode are redundant as the buffer enabled bit can be used. wow. I was impressed. one look and he removed a bunch of code in the driver because it is there in the subsystem already. just check a boolean!!

he wanted some comments about irqs that i have to look into. i didnt know the answer directly lol.

this upstream thing is tricky stuff!

In any case, I have one ack which at least fixes the adc for one-shot mode in the mainline!
now for continuous mode.. I wanted to fix the triggers too. Lets see..

ZubairLK

Upstream effort part 1

I'm not expecting the mainline to welcome all the patches with open arms :p

But let the bashing begin. :)

Upstreaming continuous support for the ADC drivers for the BBB.

http://thread.gmane.org/gmane.linux.kernel.iio/8197

Project video

A bit late. but better late than never :)

I liked the idea of two narrating robotic voices from a youtube video once. the cooler software xtranormal is being shutdown. But this goanimate website is cool stuff too.

Exporting the video to youtube costs money lol. i'll pay the fee if it passes bb.org and is needed on youtube. Their own online player is pretty cool. Should be sufficient.


gsoc project video beagleboard by ZubairLK on GoAnimate

Continuous sampling mode for ADC driver for BBB. Kernel 3.10!

EDIT. THIS IS AN OLD POST.
READ THIS FOR UPDATED INFORMATION
http://beagleboard-gsoc13.blogspot.com/2013/07/sampling-analogue-signals-using-adc-on.html


Finally got it to work!

That was a rather large pain. And I'm not sure how it will be received by the mainline folk either.

Basically the 3.2 based tree by TI had patched their am335x driver for continuous sampling. However, iio had changed quite a bit from 3.2 till 3.10.

Forward porting all changes meant going through everything and checking the latest stable drivers to see what the difference was. The differences were minor. But there nonetheless..

And this is a rather large changeset! I was concerned that the patch was becoming rather huge. But then. It is a rather large feature. So can't do this in small increments.

The first patch adds continuous sampling and some fixes to it all bundled together. The original author is Patil Rachna. I kept the bug fixes later on by Russ dill as separate patches.

Thank-fully the driver was there and I was only reworking it. Going through the TRM helped a bit in understanding the flow a bit. But I didn't have to make it from scratch which would have been an even bigger pain. Especially as the TRM can be very cryptic..

Patches available at

https://github.com/ZubairLK/kernel/tree/3.11/patches/adc

Ring Buffer issues

Access to the ADC using the /dev/iio entries is supported on the kernel side by implementing buffers.. /dev/iio is basically used for continuous sampling.

One-shot sampling is implemented via the sysfs interfaces. One-shot is up and running. So now I turned my attention to continuous sampling.

TI has implemented it for 3.2 in the following commit.
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=b332370651a7d64d3c6ed8780d939fc18163e141;hp=09597d7a244a8e6f5ea79da3c5dced3a5ea620c4

I went through it manually and applied all the changes to my adc file.

However..

I found out that it was a big time waste. The underlying buffer being used by the driver in the 3.2 based tree was implemented in ring_sw.c

This buffer was depreciated and none of the drivers use it any more!
The linux kernel has moved on to another kfifo based implementation or something.

This patch is might require some really nitty gritty work.. Or it might just be a few carefully chosen lines to replace..

Uboot tftpboot notes

https://gist.github.com/17twenty/2718613 Good stuff on automating tftp boot.

uenv to boot from the kernel on my laptop

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; bootm 0x80200000

Pull requests

Took a while to get git up and running the way i wanted.
It can have a steep learning curve!

And we have pull requests
https://github.com/beagleboard/kernel/pull/48 for the 3.8 tree
https://github.com/beagleboard/kernel/pull/47 for the 3.11 tree

Time to chill for the weekend!
:)

Update. They've been merged. Yeaaaaaaaaaaa :)

4 wire resistive touchscreen HW emulator

 
While the TSC is on its way, I couldn't just move on with tinkering the ADC drivers without knowing if I've accidentally broken the TSC ones.

So here comes the hardware 4 wire touchscreen emulator!

Folks at #beagle-gsoc were pretty helpful in guiding me on how to test the TSC without the TSC.

"evtest /dev/input/touchscreen0 " runs a great utility detecting touchscreen input.

And the hardware is just resistors/potentiometers.

I googled and after a while. This is what I could come up with. Note : Dont use 100K ohm resistors. I tried. It doesnt work. :p
These are in the range of 10K ohms.

The circuit is kinda like.

AIN0 --- Pot1        Pot4 ---AIN2
               |               |
                    Pot 3
                      |
                  Button
               |               |
AIN1 --- Pot2          Pot5--- AIN3


evtest gives great output. pot 3 controls the pressure value.
pot 1/2/4/5 control X/Y coordinates.

So.
Who needs a touchscreen when you have potentiometers! :)

One-shot ADC reading in 3.11

I successfully reinvented the wheel :)

After realizing that IIO was disabled in Kconfig, it was easy once things started running somewhat. Previously it'll all be just blank!

Manually re-based the patches that I had done previously for 3.8.

I have one-shot ADC reading up and fixed for 3.11.

These patches can be upstreamed too! Especially the one that fixes the first sample read and the Ebusy signal bugs.

The iio-scale parameter requires a bit more refinement. At the moment, I have fixed the scale to 1800mV which is for BBB. Ideally this should be read from somewhere(perhaps a configured register..) or an input via sysfs..

I really need to get around configuring the resisters for the TSC test. Evtest works great. But I'll need switches and a few pots for a proper test bench..

Too pre-occupied with the MSc thesis during the day time.

Now for looking at how to update my github fork so that I can upload these patches and send a pull request to koen.. Have to send that pull request for the 3.8 ones too..

IIO in 3.11

It took ages to realize that IIO had not been enabled in the Kconfig file!!

I was trying to debug why the ADC wasn't working and if the DT was wrong etc.

O well.. I guess a guy has to learn these things from experience..

IIO Map for bone-helper

IIO has a map interface that was used by the bone-helper function.
This was added via a patch in the old patch series.

I didnt want to disturb people using the bone-helper function so I added the patch (after the required modifications) to my series as well.

the bone-helper now works great. Doesn't give erroneous values. And doesn't require multiple refreshes either.

https://github.com/ZubairLK/kernel/blob/3.8-adc-fixes/patches/adc/0021-Add-IIO-map-interface-for-bone-helper-Most-of-the-wo.patch

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

Uselful links

I'm loosing track of good links. So I'll keep updating this post with the ones I find along with comments.

One important thing I have realized: This isn't a project where I google around, find a blogpost. And implement all the steps in it :)

The documentation is to be found in LDD3, stack overflow questions, mailing lists and, most importantly, the kernel tree itself.




Repository of patches applied to mainline kernel to make it function on the beaglebone. My work will sum up a few patches to be added to this.
https://github.com/beagleboard/kernel/tree/3.8

Set of tutorials on linux device driver development.
http://oldpapyrus.wordpress.com/tag/write-linux-device-drivers-kernel-3-0-2-6/

IIO Subsystem documentation
http://www.ohwr.org/projects/zio/wiki/Iio Interesting wiki page giving overview.

Kernel tree maintained by TI for the AM335x processors
http://arago-project.org/git/projects/?p=linux-am33x.git;a=summary

Some drivers. (Note not the main branch..)

Touchscreen driver
http://arago-project.org/git/projects/?p=linux-am33x.git;a=history;f=drivers/input/touchscreen/ti_tsc.c;h=8b3459812fef27c3f1a7801b9bf9b3bf195e34c8;hb=v3.2-staging

ADC driver
http://arago-project.org/git/projects/?p=linux-am33x.git;a=tree;f=drivers/staging;h=7c862de9e9b05ac4577665a4ed5a554d88f27acd;hb=v3.2-staging

Touchscreen/ADC driver clash patch. Part of the project is investigating the clash between touchscreen drivers and ADC drivers. The following link is a discussion on a patch solving a similar issue for another ADC.
https://patchwork.kernel.org/patch/1851101/

I skimmed the tech ref manual of the processor. The touch screen controller is a mode of the 8 channel ADC itself. As I looked at the driver sources, I found that the touchscreen driver doesn't look like its based on the IIO subsystem. The ADC driver is. The discussion in thehttp://ez.analog.com/community/search.jspa?peopleEnabled=true&userID=&containerType=&container=&q=sysfs+iio link above indicates that this is an issue in the design of the subsystem itself. It hasn't yet been designed to acknowledge that part of the ADC channels can be under use by a touch screen controller.
I will look into it as time goes on.

Analog devices wiki page on IIO
http://wiki.analog.com/software/linux/docs/iio/iio
Their ADC drivers can be a good source of example. Although, the SPI/I2C interface creates a bother. I should look at processor ADC drivers to see if I find a great one. The TI mainline one is more refined as well..

Analog community forums are slightly hidden but a good source on IIO recent questions..
http://ez.analog.com/community/search.jspa?peopleEnabled=true&userID=&containerType=&container=&q=sysfs+iio

ADC heaven for the beaglebone! Gives a great overview of the driver..
http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver%27s_Guide

This guy is great with the beaglebone :)
http://hipstercircuits.com/
http://hipstercircuits.com/reading-analog-adc-values-on-beaglebone-black/ 

Temp sensor using ADC on beaglebone
http://bwgz57.wordpress.com/2012/04/01/beaglebone-how-hot-is-it/

Interesting driver guide
http://www.cedt.iisc.ernet.in/people/haresh/emsys/device_driver_brief_tutorial.pdf
 

I'll update this list as time goes on. Pretty sure I missed out on a few links already.. But I need to focus more on the content in the links itself rather than documenting the links.. :)

Getting to the latest kernel tree of the beagleboard

This is a tricky one.

"The BeagleBone currently relies on a number of out-of-tree kernel patches in order to boot. These patches are maintained by Koen Kooi (CircuitCo) and come from many sources, including TI employees and various mailing lists." from the Beagleboard GSoC ideas page.

A cursory look at https://github.com/beagleboard/kernel will show you a patch script file you need to run. A closer look inside it shows that it builds the 3.2 kernel version. I knew that the current version under development was 3.8 so I figured out that something is fishy.



Turns out the 3.8 tree is being developed in a branch (i think. still not comfortable with git). Selecting the 3.8 branch from the branches will show the current kernel being maintained by Koen.

Edit: Epiphany. I'm guessing the 3.2 branch is stable with respect to various drivers! That is why the master points to the 3.2 kernel tree.

For the 3.8 tree, using git clone on the main link

git clone https://github.com/beagleboard/kernel

will give you the current head which points to 3.2 version. Then you have to

git checkout origin/3.8 -b 3.8

in the same folder. This will change the head to point it to the 3.8 branch.

Then you will need to run ./patch.sh which will generate a working kernel tree for you.

I'm updating the log as I go. I'm pretty certain git will work its magic and I'm about to see a functioning kernel tree in my directory.

All this should be basic stuff for gurus and developers comfortable with git.
I'm writing from a novice perspective..


Cheers
Zubair

p.s. One thing I have realized is that date stamps are very important. Old blog posts can only be treated as reference material. The open source community has a fast pace.

Workstation setup

I have set up a clean install of Ubuntu 12.04 LTS with 150gb in the home directory and 50gb for /

I was thinking I might need a better setup to browse the kernel sources.

Tried to set up the latest LXR (linux cross reference) but got stuck in weird scripts and bugs.

Set up the old version using http://thangamaniarun.wordpress.com/2010/07/09/howto-setup-lxr-on-linux-ubuntu-10-04/

Realized LXR can't be the main tool. Just sometimes to browse the original kernel tree and trace data structures and functions.

Trying to work using LXR for anything else would get messy. LXR is a great tool. But my current work is focused on the ADC drivers. I don't need to browse everything all the time. And the online lxr is pretty great as well.. http://lxr.free-electrons.com/

Set up open embedded using http://www.angstrom-distribution.org/building-angstrom. I should really ask koen to write a line there to install a dozen relevant packages (required for bitbake) before those instructions can be followed.

I think this covers it all but I'm not sure. Taken from https://pixhawk.ethz.ch/tutorials/omap/openembedded_bitbake_installation

sudo apt-get install subversion cvs git-core \
build-essential help2man diffstat texi2html texinfo \
libncurses5-dev gawk python-dev python-psyco python-pysqlite2 \
 gnome-doc-utils gettext automake flex bitbake

Realized working on the kernel under OE will be a significant pain. Googled around. Found these

http://www.linuxtogo.org/gowiki/CompilingYourOwnCode

http://ao2.it/en/blog/2010/05/27/neat-compilerun-cycle-git-and-openembedded

http://bec-systems.com/site/521/best-practices-for-kernel-development-with-openembedded

I'll use the toolchain from OE. And set up a separate kernel tree to work with. 

To my current knowledge, work in the OE tree would be adding a line or two for a few additional patches later on. But right now. I have no use of OE. I need a base stable kernel tree with the patches for the beagleboard kernel that I can branch of using git and work on the ADC driver..

"Edit update: Found http://www.slimlogic.co.uk/2011/05/openembeddedangstrom-kernel-workflow/

Which illustrates a very useful work-flow.. I'll look into it."

What next?

Learn git. The more time I spend on git now, the better I'll be able to work later on..

I'll be following tutorials online like https://github.com/gregkh/kernel-tutorial . And setting up a kernel tree now.

Cheers

Zubair

Hello World

Hi,

My name is Zubair Lutfullah Kakakhel and I will be working on the Beaglebone black for the Google Summer of Code 2013 project. (GSoC website link).

This blog will act as a log/journal as I work on the project.

Project overview

The IIO ADC driver for the Beaglebone does not add /sysfs entries and the /dev/iio:deviceX entries are slightly broken.

This project will involve patchwork for the ADC drivers.

An hwmon driver will be developed for power measurement using the 7th ADC channel connected to the shunt register.

Community members report touch screen drivers clashing with the free ADC channels. This will be investigated and patched.

The kernel tree maintained by TI for the AM335x has quite a few updates to the ADC driver which haven't been merged into the main kernel tree.
These updates will be forward ported to the tree used by the beaglebone black.

PWM driver has a hack for adding sysfs entries. Clean sysfs support for the PWM driver api will be written.

These drivers,fixes and associated test applications will greatly help new comers and userspace application programmers to easily access the ADC on the beaglebone.

My background

I am currently doing an MSc. in Embedded Systems at the University of Leeds, UK.

I have worked on the Beagleboard-XM for around two years during my undergraduate and afterwards during my job.

I have completed a Bachelors in Electrical Engineering from National University of Sciences and Technology, Pakistan.



On the personal side, I'm a geek and I know it. :)
I like traveling and photography these days.


Cheers,
Zubair