> -----Original Message----- > From: Michael Welling [mailto:mwelling79@xxxxxxxxx] On Behalf > Of Michael Welling > Sent: Tuesday, August 18, 2015 10:37 AM > To: Greg Wilson-Lindberg > Cc: Daniel Baluta; linux-iio@xxxxxxxxxxxxxxx > Subject: Re: BBB IIO ADC access not working > > On Tue, Aug 18, 2015 at 09:54:47AM -0700, Greg Wilson-Lindberg wrote: > > > > > > > -----Original Message----- > > > From: Michael Welling [mailto:mwelling79@xxxxxxxxx] On Behalf Of > > > Michael Welling > > > Sent: Tuesday, August 18, 2015 9:29 AM > > > To: Greg Wilson-Lindberg > > > Cc: Daniel Baluta; linux-iio@xxxxxxxxxxxxxxx > > > Subject: Re: BBB IIO ADC access not working > > > > > > 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? > > > > I don't know how long the system runs before lockup. The > -r73 kernel > > locked up Sometime over the weekend, I had run it for an > hour or two before I left Saturday. > > The -r62 kernel again, ran for a couple of hours yesterday > afternoon before I went home, it was locked up this morning. > > > > > > > > Previously it was in a few seconds so there is obviously some > > > improvement. > > > > I've seen uptimes of a few hours before depending on the > config-delay setting, which I think that I have set to <0xB000>. > > > > > > > > Is the mouse locked as well after the overnight test? > > > > Yes the mouse is locked up for touches, but it does still > move. The GUI loop for the program is still running. I've got > some indicators on the screen that are still updating. > > > > Does the cursor jump to a specific place on the screen when > you stop moving the mouse? No, it follows movement and stays at the last location it was moved to. > > > > > > > > > > > > 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
