On Wednesday 22 July 2009, Mark Brown wrote: > Yes, I think that'll be required for users like gpiolib. If someone's > done something like have a button implemented by attaching switch to a > GPIO input on for something like jack detect on an audio CODEC or a wake > source for a PMIC then we've got generic code that expects to just take > a gpio/irq and interact with it. Is there a problem with how it works now? GPIO calls come in sleeping (e.g. over I2C or SPI) and non-sleeping (classic SoC GPIOs) varieties. And it's not gpiolib which would handle any IRQ support ... it's the driver for the GPIO chip, which would expose both irq_chip and gpio_chip facets. (Just like classic SoC GPIO drivers.) So if a handler uses only non-sleeping calls, it needs at most minor tweaks to make sure it can be used from a threaded context. If it uses sleeping calls, it already has to arrange that it runs in a threaded context. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
