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