On Wed, Oct 24, 2012 at 6:14 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote: >> - we ask another layer to allocate memory for us >> - we ask another layer to call our ISR once the IRQ line is asserted >> - we ask another layer to handle the input events we just received >> - we ask another layer to transfer data through DMA for us >> - we ask another layer to turn regulators on and off. > > But we are _directly_ _using_ all of these. You allocate memory and you > (the driver) stuff data into that memory. You ask for DMA and you take > the DMAed data and work with it. Not so with pinctrl in omap keypad and > other drivers I have seen so far. Consult: drivers/tty/serial/amba-pl011.c drivers/spi/spi-pl022.c drivers/i2c/busses/i2c-nomadik.c for more complex pinctrl use cases. These are my dogfood drivers ... Most of these will request more than one state and switch the driver between these different states at runtime, in these examples for power saving there are states named "default", "sleep" and in the I2C driver also "idle". These examples are more typical to how the ux500 platform will look, also the SKE input driver will move the devise to sleep/default states but we need to merge PM code before we can do that. Yours, Linus Walleij -- 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
