Thanks Linus!
/Andrea
On 18 June 2013 16:48, Linus Walleij linus.walleij@linaro.org wrote:
On Tue, Jun 18, 2013 at 1:02 PM, Andrea Gallo andrea.gallo@linaro.org wrote:
and we need to add pinmux and piniocontrol in the picture somewhere :-) is it below the linux gpio layer?
Thanks for poking...
Nonetheless, here's the simple bit of ASL I'm using for GPIO right now:
This is interesting!
Scope (_SB) {
// Base Address: 0x11400000 Device (GPA0) // GPIO controller GPA0 { Name (_HID, "LINA0002") Name (_UID, 0x00) Method (_CRS, 0x0, Serialized) { Name(RBUF, ResourceTemplate () { Memory32Fixed (ReadWrite, 0x11400000, 0x18) GpioIo (Exclusive, PullDefault, , // debounce timeout , // drive strength , // IO restriction "GPA0") { // pin numbers 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 }I don't know the rest of the comments here, but in Linux we have separate concepts for GPIO and pin control. The reason is that Grant (then the GPIO maintainer) did not want to extend the GPIO subsystem with all "special extras" dealing with pin multiplexing and pin configuration (other electrical properties).
So GPIO in Linux is just some external lines. All the fine-grained control stuff here like debounce timout, pull up/down, drive strength etc will have to be modeled into pin control.
However in practice I don't think it's a big problem, we will just put a combined GPIO+pinctrl driver for ACPI in drivers/pinctrl and it will handle GPIO and pin control properties alike.
I only recently forced Intel to do this for their Bay Trail processor and I have the patch in the mail right now (haven't reviewed it yet).
Yours, Linus Walleij