> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx > [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Wang > Sawsd-A24013 > Sent: 2009年6月5日 1:43 > To: Kevin Hilman > Cc: linux-omap@xxxxxxxxxxxxxxx; nm@xxxxxx; Mike Chan > Subject: RE: [PATCH] OMAP2/3 Avoid GPIO pending irq status > been set after irq_disable > > > > > -----Original Message----- > > From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > > Sent: 2009年6月5日 1:04 > > > > Dumb question: Why use level? Why not use falling edge for this? > > > A good question, :-) We did use edge interrupt before, see > the reason below. > > > > The issue is, after the touch driver calls irq_disable, > since it is > > > empty unless > > > Set the IRQ_DISABLED flag, so next time only the generic handler > > > function > > > handle_level_irq is called, this handler just ack to OMAP > > GPIO IRQ that > > > is > > > To clear the IRQ status and mask the GPIO on OMAP side, > but since NO > > > Touch driver IRQ action is called, so the touch Controller > > can not gets > > > acknowledged, then the interrupt line will be always driven > > low by the > > > external controller, > > > > If the GPIO is set to be edge triggered, the fact that it > is still low > > won't matter, the genirq layer will have noticed a pending > interrupt. > > > If we use edge interrupt here, the potential issue is still > existing, and also > We are liky to lose the interrupt. > After irq_disable and before HW suspend, if the interrupt > line is driven low, > Then OMAP GPIO can catch this edge transition, so the IRQ is set, > Then the handle_edge_irq will clear the IRQ staus and mask the IRQ. > Since the controller is not ACKed, then the interrupt line is > always driven low, > Then from then on, no edge can happen, and no more Touch > interrupt can happen > Even when irq_enable is called, though we have the prepare > for idle hooks, > But that only work when the edge transition happens after > that prepare call, > Since it saves the GPIO data IN at that time, if the input > level already changes > Before that time, then the workaround does not work. > > We ever made another patch to not only compare the data in, > but also check > It is rising or falling edge, and check the CURRENT input > level to decide whether to > Use LEVEL detect to manually trigger the interrupt, it works > fine with our HW. > But later on, touch cotroller driver is updated to use level > detect, then we > Met this issue. I think the patch we made to workaround the > edge int lost is also needed > In current pm branch, currently we may still face the issue I > mentioned above. I rechecked the code, seems the issue will not be there since The handle_edge_irq can resend irq during resume time, then I checked our issue log and found, the reason that we lose The edge interrupt is because we were using omapzoom kernel And put PER to fully HW supervised mode and we didn't use The prepare idle hooks in our idle function call, then the issues Happens when PER is in RET/OFF state but the touch interrupt happens. With linux-omap kernel, seems using edge interrupt can just workaround The touch issue, but I think the issue is still there, we can not expect All the GPIO interrupts to be edge type, and we can not expect all the edge Interrupts to fire only once, with open platforms, every kind of peripherals We may use, the change to root fix this problem should be still clearing The level/edge detection when irq_disable is called. This will not cause Extra interrupt loss since we still have the prepare/resume hooks to check Gpio input and retrigger the interrupts. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
