* Dmitry Torokhov wrote: > On Tue, May 17, 2011 at 08:27:16AM +0200, Thierry Reding wrote: > > [Cc'ing Kwangwoo via the alternate email address] > > > > * Dmitry Torokhov wrote: > > > On Mon, May 16, 2011 at 10:32:59AM +0200, Thierry Reding wrote: > > > > When the controller signals a pen-down event via the platform-specific > > > > GPIO, while the sample values indicate an invalid measurement, the > > > > measurement needs to be repeated. > > > > > > > > > > Would not we be interrupted again and take another sample then? > > > > Not necessarily. The problem is that if the pendown GPIO reports pendown, it > > doesn't necessarily mean that the pressure measurement will be valid. This is > > especially true if max_rt is configurable (as introduced by one of the > > follow-up patchs). > > > > What happens is that we are interrupted, check the GPIO to see that the pen > > is indeed down and then read the values and compute the pressure to see that > > it is invalid and we stop sampling. The TSC2007's nPEN_IRQ line never goes > > high again after that because the pen is still down (according to the GPIO). > > > > The comment in the old code of the (rt > max_rt) even says "[...] repeat at > > least once more the measurement", which the old code actually doesn't. > > > > I see. I am concerned with resubmitting work over and over when we do > not have ts->get_pendown_state method. I hadn't thought about that case. But it seems as if that case should behave the same and stop rescheduling work as soon as no pressure is applied and rt becomes 0. Perhaps if I change this: debounced = true; into if (ts->get_pendown_state) debounced = true; it becomes more obvious that this "fix" only applies to the case where the GPIO and pressure measurement contradict each other. Thierry
Attachment:
pgpVIh9tDJkND.pgp
Description: PGP signature
