On Wed, Jan 27, 2010 at 08:43:39PM +0100, Alberto Panizzo wrote: > Hi Dmitry, > > On mer, 2010-01-27 at 10:33 -0800, Dmitry Torokhov wrote: > > Hi Alberto, > > > > On Wed, Jan 27, 2010 at 06:50:44PM +0100, Alberto Panizzo wrote: > > > The MXC family of Application Processors is shipped with a Keypad Port > > > supported now by this driver. > > > > > > The peripheral can control up to an 8x8 matrix key pad where all the scanning > > > procedure is done via software. > > > > > > The hardware provide two interrupts: one for a key pressed (KDI) and one for > > > all key releases (KRI). There is also a simple circuit for glitch reduction > > > (said for synchronization) made by two series of 3 D-latches clocked by the > > > keypad-clock that stabilize the interrupts sources. > > > KDI and KRI are fired only if the respective conditions are maintained for at > > > last 4 keypad-clock cycle. > > > > > > Those simple synchronization circuits are used also for multiple key pressures: > > > between a KDI and a KRI the driver reset the sync circuit and re-enable the KDI > > > interrupt so after 3 keypad-clock cycle another KDI is fired making possible to > > > repeat the matrix scan operation. > > > > > > This algorithm is done through the interrupt management code and delayed by a > > > proper (and longer) debounce interval controlled by the platform initialization. > > > If a key is pressed for a lot of time, the driver relaxes the interrupt re-enabling > > > procedure to not over load the cpu in a long time keypad interaction. > > > > > > > I was looking at the debounce logic and I am not quite sure about it. > > Normally you have 2 ways for dealing with jitter: > > > > 1. You let interrupts to come in and reschedule the scan until they stop > > arriving. Then to tak ethe stable reading. > > > > 2. You inhibit interrupt, take a reading and schedule another reading in > > the future. If they match you decide that reading is stable otherwise > > you schedule another reading. > > > > In your case you seem to be simply postponing the reading but this does > > not guarantee that the reading is stable. > > Yes, because of the glitch suppression circuit, I suppose that when > an interrupt arrive, it is a key pressure for sure. > Then I assume that the matrix will be stable after a proper debounce > time (test look fine with 20 ms). > > 1 should be a more accurate way, I can study an implementation. > > > > > I also do not think that yopu need 2 timers - you can easily requeue > > currently running timer. > > The first version I made was with one timer: if for too many repeating > interrupts the matrix state do not change, the scanning procedure was > scheduled with a summed delay. > > It resulted in a degradation of responsiveness and more key pressure > losing. It is a better choice to let the scanning procedure near the > interrupt. Hmm, that is unexpected result. I am pretty sure if was implementation deficiency and you can achieve the same performance with one timer and unified timer function. > > Changing the timer handler over the time? Would be acceptable? No, it is a bad taste. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
