Kernel -bone26 ADC Problems

I am having serious problems using multiple ADC channels in the latest
-bone26 kernel. When reading more than one ADC channel, you cannot read
more than 15 samples before getting an I/O error reading the AINx file
from sysfs (Resource temporarily unavailable). The read rate doesn't
matter, the problem appears to be related to switching between the
channels somehow.

Can anyone else verify this issue?

Who gets bug reports about the BeagleBone kernel patch set? This
doesn't quite seem appropriate for the OMAP kernel list, or is it?

DETAILS TO REPRODUCE:

I have a simplistic test script to reproduce this behavior, assuming you
have previously loaded the cape-bone-iio overlay:

#/bin/sh
while : ; do
        for ADC in AIN4 AIN5 ; do
                echo -n "$ADC: "
                cat /sys/devices/ocp.*/helper.*/$ADC
                sleep 1
        done
done

When you run this, after every 15 reads of AIN4, the system throws an
I/O error and the 16th read of AIN4 fails. At this point, things seem
to reset and you can read another 15 values before the next error.

Example output:

...
AIN4: 589
AIN5: 817
AIN4: 586
AIN5: 811
AIN4: 588
AIN5: 816
AIN4: cat: /sys/devices/ocp.2/helper.12/AIN4: Resource temporarily
unavailable
AIN5: 997
AIN4: 597
AIN5: 1000
AIN4: 595
AIN5: 996
AIN4: 595
AIN5: 995
AIN4: 598
AIN5: 999
AIN4: 595
AIN5: 997
AIN4: 594
AIN5: 992
AIN4: 597
AIN5: 998
AIN4: 595
AIN5: 994
AIN4: 597
AIN5: 999
AIN4: 595
AIN5: 997
AIN4: 594
AIN5: 993
AIN4: 598
AIN5: 999
AIN4: 595
AIN5: 997
AIN4: 595
AIN5: 994
AIN4: 598
AIN5: 997
AIN4: cat: /sys/devices/ocp.2/helper.12/AIN4: Resource temporarily
unavailable
AIN5: 994
AIN4: 598
...

Hi Charles,

Interesting, I hadn't noticed a repeating cycle yet. The problem seems to be with the 3.8 kernel.
The ADC driver in the 3.2 kernel does not show this behaviour.

I can reproduce your results (using raw ADC values) reading two channels out of 8:

#!/bin/sh
while : ; do
         for i in 4 6 ; do
                 echo -n "AIN${i}: `cat /sys/devices/ocp.2/44e0d000.tscadc/tiadc/iio\:device0/in_voltage${i}_raw` "
                 sleep 1
         done
         echo ""
done

cat: /sys/devices/ocp.2/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw: Resource temporarily unavailable
AIN4: AIN6: 3522
AIN4: 3565 AIN6: 3549
AIN4: 3577 AIN6: 3530
AIN4: 3580 AIN6: 3553
AIN4: 3609 AIN6: 3545
AIN4: 3599 AIN6: 3555
AIN4: 3568 AIN6: 3555
AIN4: 3582 AIN6: 3552
AIN4: 3579 AIN6: 3554
AIN4: 3570 AIN6: 3548
AIN4: 3594 AIN6: 3527
AIN4: 3579 AIN6: 3548
AIN4: 3581 AIN6: 3549
AIN4: 3604 AIN6: 3553
AIN4: 3580 AIN6: 3552
AIN4: 3592 AIN6: 3543
cat: /sys/devices/ocp.2/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw: Resource temporarily unavailable
AIN4: AIN6: 3551
AIN4: 3571 AIN6: 3549
AIN4: 3589 AIN6: 3579
AIN4: 3583 AIN6: 3544
AIN4: 3598 AIN6: 3561
AIN4: 3564 AIN6: 3523
AIN4: 3533 AIN6: 3532
AIN4: 3607 AIN6: 3527
AIN4: 3586 AIN6: 3541
AIN4: 3622 AIN6: 3546
AIN4: 3617 AIN6: 3543
AIN4: 3600 AIN6: 3529
AIN4: 3565 AIN6: 3539
AIN4: 3574 AIN6: 3568
AIN4: 3573 AIN6: 3513
AIN4: 3547 AIN6: 3536
cat: /sys/devices/ocp.2/44e0d000.tscadc/tiadc/iio:device0/in_voltage4_raw: Resource temporarily unavailable
AIN4: AIN6: 3518
AIN4: 3572 ^C

There seems to be a dependency on the number of channels (and order of reading?)
But when I read 3 channels instead of only 2 the pattern changes, I've seen cycles of
8, 16 or no error at all.

Have you also noticed a pattern in the wrong values read back?

-- Bas

Hi Charles,

Interesting, I hadn't noticed a repeating cycle yet. The problem seems
to be with the 3.8 kernel.
The ADC driver in the 3.2 kernel does not show this behaviour.

I can reproduce your results (using raw ADC values) reading two channels
out of 8:

I get errors with the raw reads as well, which is what I typically use
for temperature sensing. I went back to the AIN values to see if that
made any change, but it didn't.

<snip>

There seems to be a dependency on the number of channels (and order
of reading?) But when I read 3 channels instead of only 2 the pattern
changes, I've seen cycles of 8, 16 or no error at all.

That doesn't seem really surprising. I didn't do a lot of testing with
multiple channels, but only one channel does seem to work OK.

Have you also noticed a pattern in the wrong values read back?

I haven't tried this on the 3D printer yet with actual thermistors, so
I'm not sure. I have a work-around that just ignores read errors from
the ADC and continues on, but that seems like a lousy way to fix the
problem, so testing is still on a 'bare' BBB with no BeBoPr cape.

Have either of you seen any updates on fixes for this? I have done some searching and have not yet come up with anything that may fix the issue in any active kernel patches.

I am using a similar workaround to retry on failure, but am considering digging into this to fix the root cause.

Zach