Hi Dmitry, On 1/20/2011 1:43 PM, Dmitry Torokhov wrote: >>> >>> No, this it not correct. request_any_context_irq() means that you could >>> either get a hardirq or a treaded one. However above you are changing to >>> gpio_get_value_cansleep() which indicates that you can sleep. >>> >>> You need to either revert to gpio_get_value() or explicitly request >>> threaded IRQ. >> >> This could be problem. Say, we are doing request_any_context_irq(..) and gpio is over slow-bus, >> so we naturally get into the threaded code, and in the thread handler we are calling gpio_get_value(..), >> but in this case gpio_get_value could throw a warning that we should call gpio_get_value_cansleep(...) >> because sleep attribute is added into the gpiolib hook implementation for these gpios. >> >> Now suppose gpio is memory mapped and we enter into the hardirq and calling sleep variant into the >> handler code will be naturally bad. >> >> How about checking maysleep explicitly here while using the request_any_context_irq() call though >> the semantics of gpiolib framework discourages that. >> > > Any drawbacks for explicitly switching to threaded IRQ and keeping > gpio_get_value_cansleep()? (That was the 2nd option I mentioned BTW). > Only drawback is that you get "dedicated thread" in case the irqs are not chained handler. In worst-case it would introduce the latencies otherwise fine. ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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
