> -----Original Message----- > From: Michael Welling [mailto:mwelling79@xxxxxxxxx] On Behalf Of Michael > Welling > > It seems to have something to do with the characteristic of the touchscreen > as this does not happen on my 7" display. > > Looking at the datasheet these pin are dedicated analogs and cannot be > MUX'd otherwise. > > http://www.ti.com/lit/ds/symlink/am3354.pdf > page 20 Let me please re-ask a previously asked question just to be certain we're on the same page, because I think it is an extremely important question. As background, the analog pins you mention belong to the "TSCADC" peripheral. This peripheral, as the name suggests, has two purposes: 1. It's a touchscreen controller. For example, you might use 4 of the 8 analog inputs for the purpose of a touchscreen. 2. It's a general purpose A/D converter. The remaining unused analog inputs can be used for general purposes such as checking a battery voltage, reading a thermistor, etc. What I would like to know is how many of those 8 pins are being used. Are you only using 4 pins for a resistive touchscreen, or are some other pins being used for general purpose ADC? Let me also provide more background on why I'm asking... The patch set I created was originally developed on a 3.12 kernel. On the 3.14 kernel there were some pretty major changes done with regard to how the general purpose ADC samples are collected. So far, all the problematic areas I've bumped into with respect to integrating these patches in newer kernels have been in scenarios where there is ADC collection happening simultaneously. So I'm trying to understand if your issue falls into that bucket or is something completely different. It would be useful to probe the touchscreen signals during your test, particularly AIN0 which controls the pen-down interrupt. Fundamentally I want to understand how it's possible that you're getting a pen-down interrupt when nothing is touching the screen. I agree it's odd that you don't see the issue without my patch, though if you want to get to the heart of the issue we will need to make some observations to understand what's happening. I'm afraid we're moving in the wrong direction by just adding extra checks and filters into the kernel code. In other words, I think that's a more of a workaround than a solution, but it's hard to know for sure without some additional data points. -- 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
