On Tue, Aug 18, 2015 at 09:06:20AM -0700, Greg Wilson-Lindberg wrote:
>
>
> > 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.
> >
> >
>
> I've applied this to the ti_am335x_adc.c driver in both the 3.14.49-ti-r62 & 3.14.49-ti-r73 kernels from RCN and they both suffered touch screen lockups over night.
This is disturbing. Do you have any idea how long it takes before the lockup occurs?
Previously it was in a few seconds so there is obviously some improvement.
Is the mouse locked as well after the overnight test?
>
> Here is what I did:
> static irqreturn_t tiadc_irq_h(int irq, void *private)
> {
> struct iio_dev *indio_dev = private;
> struct tiadc_device *adc_dev = iio_priv(indio_dev);
> unsigned int status, config;
> status = tiadc_readl(adc_dev, REG_IRQSTATUS);
>
> /*
> * ADC and touchscreen share the IRQ line.
> * FIFO0 interrupts are used by TSC. Handle FIFO1 IRQs here only
> */
> if (status & IRQENB_FIFO1OVRRUN) {
> /* FIFO Overrun. Clear flag. Disable/Enable ADC to recover */
> config = tiadc_readl(adc_dev, REG_CTRL);
> config &= ~(CNTRLREG_TSCSSENB);
> tiadc_writel(adc_dev, REG_CTRL, config);
> tiadc_writel(adc_dev, REG_IRQSTATUS, IRQENB_FIFO1OVRRUN
> | IRQENB_FIFO1UNDRFLW | IRQENB_FIFO1THRES);
> tiadc_writel(adc_dev, REG_CTRL, (config | CNTRLREG_TSCSSENB));
> return IRQ_HANDLED;
> } else if (status & IRQENB_FIFO1THRES) {
> /* Disable irq and wake worker thread */
> tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_FIFO1THRES);
> return IRQ_WAKE_THREAD;
> }
>
> if (status & IRQENB_EOS) {
> tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_EOS);
> return IRQ_HANDLED;
> }
>
> return IRQ_NONE;
> }
>
> Regards,
> Greg
--
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
