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..
Beaglebone Black GSOC 2013
Sunday, 22 September 2013
Wednesday, 18 September 2013
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
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 :)
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
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
Tuesday, 17 September 2013
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..
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..
Tuesday, 10 September 2013
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..
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..
Tuesday, 3 September 2013
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.
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.
Subscribe to:
Posts (Atom)