BUGGGGGGGGS

I have noticed three(lol. Update. 6 now) bugs in the TSC ADC driver.

Subtle ones. Quite possible won't occur in use cases at all.

Bug 1. (resolved)

When I am waiting for a trigger, the touchscreen stops working..

This one is cause the following line on the ADC side disables the TSC steps.

 tiadc_writel(adc_dev, REG_SE, 0x00);

the tsc is ok after trigger.
But if i do an event during waiting for trigger.
tsc works. but adc doesnt. meaning tsc is disabling all configuration i did for continuous mode!

Managed to move around the bit masks to the poll handler function.
This one is ok.

Heard back from iio list with some comments.
I'll resend the patches with this bug fix squashed in.

Bug 2. (sudo resolved)

If I do a
while(true)
do
cat in_voltage*
done

to continuously read samples using one-shot adc mode.

The touchscreen registers clicks randomly!!

Although this is a wild test case, it shouldn't happen

Update: 
This is weird. Shouldn't waste time on this bug.

while (true)
do
cat in_voltage4_raw;
cat in_voltage5_raw;
cat in_voltage6_raw;
cat in_voltage7_raw;
done

wouldn't make the tsc register events or go haywire.

but

while (true)
do
cat in*;
done

would register events on TSC. Strange. I quadruple checked all the ADC reg configs even! everything is ok. The TSC shouldn't receive interrupts.

What happens is that HW steps which aren't supposed to run unless a touch is registered actually do seem to run 'once'.
This fills FIFO0 which threshold interrupts.

Thus, a random click and PEN UP somewhere. Uncool.
But anyways. Seems random. Especially since the expanded while loop didn't register the same phenomena.

Useless. No more time wasting on this bug. managed to catch another unknown one during this process lol. bug 4!.

I have to say. The more bugs I encounter. The more I understand the driver and TSADC module. The more I realize I know nothing!

Bug 3. (left for later)

This one is even more subtle.
The old 3.8 touchscreen driver was very smooth and registered clicks properly.
The one after sebastians patches seems as if the mouse is going slightly haywire sometimes.
Sometimes click takes the mouse somewhere random. This is a really subtle one.

I'll spend time on this if I get the chance. My focus is more ADC. But obviously. Community is community. And I'm in a good position to fix this.
Basically have to compare the previous driver and the one after sebastians patches in mainline. Somewhere some calculation(i guess) is different. Although sebastians work is based  on the same arago. But something feels off..

Bug 4. (Resolved. Patch upstreamed :) )

This time its the MFD driver. the MFD driver has a small function to update the Step enable register.
Problem is. It used a reg_cache. Which isn't updated anywhere. So if I use a TSC and ADC. The reg_cache gets loaded with FFFF and all steps are enabled no matter what. ADC steps disable themselves after one sample. Which makes it ok.
But sorta. The FIFO1 still gets filled up with samples.
 
The current read_raw code was ok in the sense that it flushed the entire fifo.
But too many TSC touches and the ADC FIFO will fill up with useless samples. That'll make a mess most probably.
So yea. good thing I caught this bug. I'll send it as a fix to the MFD list..

(OOO. Just realized. Steps updation might be why continuous Bug 6 isn't working. Damn. I'll have to check again..) (Update again lol. Dimitry from input pointed out as well. IRQs might be hanging..)

Fix was simplish.
added a read in there which checks current steps.

Bug 5 (Resolved!)
This is a fine example of a bug you add for no reason and then have to fix!

I was aiming to optimize the read_raw function. But indirectly added some redundant samples that wouldn't flush. This would make a mess.

If I read channel 5, I'd return early thinking I was efficient. Didn't realize Channel 6 and 7 would be in FIFO and those needed flushing.

So if i read channel 7 after 10 sec. I'll get the old value. And more old data would be in the fifo. "Unoptimized the bug again". I'll squash this fix in the next series I send to IIO.

Although I personally don't like the idea of sampling all channels and then flushing them out. the continuous mode code can be used to enable one channel only. Its a simple mask.

But alas. I'll see if i want to clean up things. it works as it is anyways..

Bug 6 (WIP)
I dont know if this is a viable test case or not.
A simple delay in a userspace application might make this go away. But yes. its bad.

While waiting for trigger.

If i'm pressing down on TSC,

and trigger the adc.

The entire TSCADC module hangs. Nothing works.

I think the IRQs hang somehow. Cause cat /proc/interrupts stops registering anything.

Maybe both handlers return none or something. And the IRQs of the TSCADC module don't occur again.
Tried moving around stuff to end. But didn't work.
Added ovverun handling but nope.

Russ tried pointing it out on a patch. But Greg said level interrupts are ok.

(Update, Dimitry from the input list pointed out the same for the patch I sent. What will happen if both IRQs go off.. Thats why system hangs maybe..)

I guess this might be something really quirky.
Its an awful usecase anyways..

Maybe both overrun and stop the TSCADC module. and the IRQ handlers don't go into ovverun. This is quirky to debug.

If I'm making a GUI running on TSC acquiring samples. I'll add a delay between the button press and the ADC sampling to avoid this race condition.

But yea. something like a GUI oscilloscope on a BBB might seem far of. I don't think the module can handle such complexity for real time sampling and display.
But sorta periodic trigger buffer sampling display might work. Anyways.
Oscilloscope on BBB might be a fun idea but I need to work on the GSoC project for now!