On Fri, Aug 14, 2015 at 03:40:18PM -0500, Michael Welling wrote:
> On Fri, Aug 14, 2015 at 11:43:52AM -0700, Greg Wilson-Lindberg wrote:
> > Thank you very much,
> > Regards, Greg
> >
>
> To replicate the issue I did the following:
>
> - Started a touchscreen enabled application
> ts_test
>
> - In another terminal started a dump of /dev/iio:device0
> hexdump -C /dev/iio\:device0
>
> - In yet another terminal enable the buffer
> cd /sys/bus/iio/devices/iio\:device0
> echo 1 > scan_elements/in_voltage4_en
> echo 1 > buffer/enable
>
> Once the buffer is enabled the hexdump window starts spewing out readings as
> expected. The touchscreen is unresponsive as expected.
>
> Then I started occassionally enabling and disabling the buffer and noticed
> something very off. When enabling the buffer sometimes the readings from
> the hexdump would start and abruptly stop. In this state the entire system
> is nonresponsive. None of the terminals are excepting input and the system is
> in complete deadlock. Then I touched the screen and the deadlock is lifted
> and readings started again.
>
> As if the behavior was not weird enough, occassionally after the buffer is
> disabled, the touchscreen readings are mangled.
>
> Next step, figure out what is going wrong.
>
It seems the drivers are being flooded with IRQENB_EOS interrupts causing
the lockup.
By adding the following to the tiadc_irq_h function the lockup stops.
.
.
if (status & IRQENB_EOS) {
tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
return IRQ_HANDLED;
}
.
.
Now the IRQENB_EOS is also handled in the touchscreen driver so this is
may not be an appropriate fix but at least it fixes the lockup.
Try adding the snippet above to ti_am335x_adc.c and see if it makes
your program stop locking up.
Then we need to find a solution that makes the maintainers happy.
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
