On Fri, Mar 27, 2015 at 11:36:25AM +0100, Linus Walleij wrote: > On Fri, Mar 27, 2015 at 11:06 AM, Mika Westerberg > <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > On Thu, Mar 26, 2015 at 06:28:19PM +0200, Octavian Purdila wrote: > > >> For the sleep case I think the GPIO controller needs to do the pin > >> enable and set input direction operation in it's irq_bus_sync_unlock. > > > > I wonder how DT handles all this? Is it the boot firmware that sets up > > the pins accordingly or is there something we are missing? > > DT systems mostly do not have firmware for power usecases, they > handle it all using pin control. I would more say that is a feature of > all-SW systems without power-firmware ideas, without ACPI and > without PSCI (well PSCI systems do not care about much more > than CPU power down in firmware anyway...) OK, thanks. In case of ACPI (where firmware does lot more) it is supposed to configure pins based on what is connected, if the firmware knows that. Due to bugs in the boot firmware that obviously does not happen in all cases (like this one). If we want to support requesting IRQ directly through irqchip interface on ACPI systems there needs to be some way the GPIO/pinctrl core can use to turn the pin as input, GPIO mode. Octavian's patch does that but not sure if it is good idea for non-ACPI systems as they already work. We could also do the same in GPIO/irqchip drivers but there is no guarantee for the caller that it is done. IMHO safest option is to explictly request the GPIO, turn it input and then convert the GPIO to interrupt. That way we know the pin is configured just like we expect. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
