RE: BBB IIO ADC access not working

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@xxxxxxxxx] On Behalf 
> Of Michael Welling
> Sent: Tuesday, August 18, 2015 11:13 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 10:40:44AM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > -----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.
> >
> 
> I found that handling the IRQENB_EOS interrupt in the ADC is 
> causing an undesired effect. After enabling the ADC buffer 
> mode and disabling it the coordinate readings work but the 
> touch release is no longer detected.

Can we put your code in the touch screen handler? The tsc code is writing to the IRQSTATUS register, not the IRQCLR register.

>  
> > > 
> > > > > 
> > > > > > 
> > > > > > 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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux