2014-11-21 23:25 GMT+01:00 Griffis, Brad <bgrif...@ti.com>: > >> -----Original Message----- >> From: Richard Cochran [mailto:richardcoch...@gmail.com] >> >> On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote: >> > Before the patches were also jumps but I thought it is something >> > Vignesh should know. Maybe there is some fix for that too? > > I believe I've seen the "jumping" behavior pop up at a couple random times in > my testing. I think it relates to the hardware not properly registering a > pen-up interrupt. When that's happening can you try running ts_calibrate? > If you're not registering a pen-up event then you won't be able to advance > through those touch points. Is this behavior related to capturing ADC > samples, or do you see this behavior even without capturing ADC samples?
Is it the right way to test? Because I think the ts_lib will cover misbehavior of the touchscreen driver. > >> > As Richard also noted, it would be nice if ti could let us know how to >> > get the delay values right. By trial and error is IMHO not the best >> > way. >> >> That is not only an opinion, it is a matter of fact. TI really dropped the >> ball on >> this one. I thought the patch series was a sign they finally were going to >> properly address this issue. Wrong again. > > These patches originate from work I did on TI's SDK 7.00 (3.12 kernel). The > touchscreen is working beautifully in that environment and we are putting > forth significant effort to bring those improvements to the community. > > Things do not seem to be working as well with the current mainline kernel. > I've been reviewing various patches between 3.12 and the mainline to > understand why it's different. I believe I have figured this out, and I have > discussions going separately with individuals that contributed those patches > in order to come up with the best possible solution, i.e. we likely need a > few additional changes to this patch set. Ok, then I'm looking forward for a new patch set to test. Furthermore, I would be interested which changes you are talking about. > > The CHARGECONFIG delay serves precisely the same purpose as the udelay in the > original code base. How did you determine the udelay value in the first > place? I went through the effort of figuring out a way to make the delay > into a HARDWARE delay instead of a software delay so that it could be removed > from the ISR. That delay time relates to "settling time" and so it's going > to be dependent on your PCB. You could hook up an oscilloscope and attempt > to capture this parameter from the signals themselves. Personally I think > that's a lot more difficult than just doing a few iterations of testing. I did measure with an oscilloscope to get the right charge delay and it looks fine to me. But I can't affect the jumps with the charge delay, the only thing that helped, was to add some sample delay. But it didn't solve it. > >> The data sheet for the TI part used to have a reference to an app-note for >> the touch controller. >> >> spruh73f page 1154 >> >> The Pen IRQ can only occur if the correct Pen Ctrl bits are high >> (AFE Pen Ctrl bits 6:5 in the TSC_ADC control register) and if >> the correct ground transistor biasing is set in the StepConfig >> [N] Register. Refer to the application notes for the correct >> settings. >> >> I searched high and low for this application note. Then, the data sheet got >> revised. > > Such an application note does not exist, which explains why you didn't find > it and why we have removed that reference from the TRM. Sorry for your > trouble. We always strive for accurate documentation. Thanks, Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
