I’m having a lot of trouble with the ADC on 3.8.13, is anyone else experiencing this? I’m often getting -EAGAIN error code and at some point it all stops working completely giving only these errors. I’m now using only a single Python thread for reading the values. @Zubair_Lutfullah have you experienced this? You have worked on this over the summer. @Charles_Steinkuehler is this the error you have blogged about?
I believe that was the problem I have seen. I was even able reproduce the issue from the command line (all you have to do is read more than one ADC channel) so it’s a driver issue and has nothing to do with timing or trying to read too fast. There are some details of the issue I was having in a post to the BeagleBoard group: https://groups.google.com/d/msg/beagleboard/99kDAfTs_ds/JJBx0r9ShCAJ
The shell script was throwing a “Resource temporarily unavailable” error, which could be the same as your -EAGAIN error in python. I don’t recall the specific python error I was seeing, other than it was an I/O error.
For me, the pattern of good reads vs. errors was fixed with a given read pattern (ie: 15 good reads then an error), but would change depending on how many and which which specific channels were being read. If you only read one channel, the errors don’t seem to occur.
This is definitely the same problem. I see that -EAGAIN (resource temporarily unavailable) is returned on two separate occasions from that driver, so I’ll try to add some more debug info to narrow it down. This is a show-stopper for me, so I need to get it sorted.
Best of luck! Holler if you need help. I don’t fancy myself a kernel developer, but I seem to keep get pulled in that direction, and I am very comfortable around low-level code. I design hardware and write VHDL code for my day job.
Well, one fault that is happening is that for each one-shot, all channels from the DT overlay are enabled, but the FIFO is not cleared of the other ADC values, so they start to pile up.
I sincerely apologize for my absence. I just got married and am busy 
if i remember correctly, my latest work was merged in 3.12. And I ported(didnt merge) or didn’t port it back to 3.8.13. I am sure I intended to.
As for the single shot reading via sysfs. If you read it too quickly in a while loop, it would return an error. I tried tracing iot. But it seemed like a very wierd bug.
And the fifo is not cleared of other values. I remember I fixed that in mfd in mainline and 3.12.
@Zubair_Lutfullah are you saying that single shot via sysfs works in 3.12? It seems as though there is some trouble with the assigning of channels to steps in 3.8, also polling SEQ_STATUS seems to miss the event some times. Ideally this should be handled asyncrchonously since it’s an event.
Some of my notes during this debugging are here
http://beagleboard-gsoc13.blogspot.com/2013/08/buggggggggs.html
Extract :
"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."
Ok, What I’m seeing is something similar to what you are describing. Step 16 which is configured as software one-shot, suddenly starts filling up FIFO1 without being enabled by the driver. But also, if I try to read back the STEPENABLE register, step 16 is always 0 even right after setting it to one.
This causes timeouts since the ADC never becomes idle.
Are you using TSC as well?
There was a bug on the TSC side. Where it would enable the ADC channels and fill the ADC fifo on every TSC event…
I fixed it in 3.12…
Sorry but I’m still in wedding mode and not coding properly…
That patch is still under discussion. There is some confusion. It has been applied though.
Ok, so I’ve done some changes to the ADC driver so to now checks for END_OF_SEQUENCE instead of polling the status register. This, in addition to flushing the FIFO each time the SW adc is called seems to do the trick. FIFO overflow for the ADC is not enabled in 3.8, so there is no need to do any reset, but if it is to be enabled at any point, I’ve added a “make sure ADC is idle before turning on”-patch. Now, this has not been tested together with TSC, so that needs to be done, @Zubair_Lutfullah do you want to do a review of the patch? Just a few lines, I think.