Sorry I did not send this out sooner -- I rewrote it a several different times over the last week to play with some ideas...
Nonetheless, here's the simple bit of ASL I'm using for GPIO right now:
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 } }) Return(RBUF) } } }
This is still not quite working in the Samsung gpiolib code just yet. They never really used FDT before (or at least, not in a way I would consider proper) so I'm having to unwind some partial movement to FDT and their specific data structures.
GPIO interrupts are not going to be much different but I don't have a good example to send out just yet.
You should be able to figure out the address from the current FDT. The pin numbers are much better hidden in mach-exynos/include/mach/gpio.h. Sometimes it's easier just to read them from /sys :).
I put this in an SSDT just for grins, but it can also go in the DSDT.
On 2013-6-18 1:16, Al Stone wrote:
Sorry I did not send this out sooner -- I rewrote it a several different times over the last week to play with some ideas...
Nonetheless, here's the simple bit of ASL I'm using for GPIO right now:
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 } }) Return(RBUF) } }
}
This is still not quite working in the Samsung gpiolib code just yet. They never really used FDT before (or at least, not in a way I would consider proper) so I'm having to unwind some partial movement to FDT and their specific data structures.
GPIO interrupts are not going to be much different but I don't have a good example to send out just yet.
Hi Al,
Have you considered about GPIO-signaled ACPI Events in GPIO ASL?
Thanks Hanjun
You should be able to figure out the address from the current FDT. The pin numbers are much better hidden in mach-exynos/include/mach/gpio.h. Sometimes it's easier just to read them from /sys :).
I put this in an SSDT just for grins, but it can also go in the DSDT.
On Mon, Jun 17, 2013 at 11:16:12AM -0600, Al Stone wrote:
Sorry I did not send this out sooner -- I rewrote it a several different times over the last week to play with some ideas...
Nonetheless, here's the simple bit of ASL I'm using for GPIO right now:
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 think this is correct, you are effecticely reserving the GPIO pins inside their own definition so nothing else can ever use them. I think these resources should only be the Memory32Fixed section. The driver then creates the GPIOs. There is then a function in acpi to map ACPI gpio -> linux gpio when other drivers need to make use of them.
Thanks
Graeme
}) Return(RBUF) }
} }
This is still not quite working in the Samsung gpiolib code just yet. They never really used FDT before (or at least, not in a way I would consider proper) so I'm having to unwind some partial movement to FDT and their specific data structures.
GPIO interrupts are not going to be much different but I don't have a good example to send out just yet.
You should be able to figure out the address from the current FDT. The pin numbers are much better hidden in mach-exynos/include/mach/gpio.h. Sometimes it's easier just to read them from /sys :).
I put this in an SSDT just for grins, but it can also go in the DSDT.
-- ciao, al
Al Stone Software Engineer Linaro Enterprise Group al.stone@linaro.org
Linaro-acpi mailing list Linaro-acpi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-acpi
and we need to add pinmux and piniocontrol in the picture somewhere :-) is it below the linux gpio layer?
(adding Linus W in cc here)
/Andrea
On 18 June 2013 12:46, Graeme Gregory graeme.gregory@linaro.org wrote:
On Mon, Jun 17, 2013 at 11:16:12AM -0600, Al Stone wrote:
Sorry I did not send this out sooner -- I rewrote it a several different times over the last week to play with some ideas...
Nonetheless, here's the simple bit of ASL I'm using for GPIO right now:
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 think this is correct, you are effecticely reserving the GPIO pins inside their own definition so nothing else can ever use them. I think these resources should only be the Memory32Fixed section. The driver then creates the GPIOs. There is then a function in acpi to map ACPI gpio -> linux gpio when other drivers need to make use of them.
Thanks
Graeme
}) Return(RBUF) } }
}
This is still not quite working in the Samsung gpiolib code just yet. They never really used FDT before (or at least, not in a way I would consider proper) so I'm having to unwind some partial movement to FDT and their specific data structures.
GPIO interrupts are not going to be much different but I don't have a good example to send out just yet.
You should be able to figure out the address from the current FDT. The pin numbers are much better hidden in mach-exynos/include/mach/gpio.h. Sometimes it's easier just to read them from /sys :).
I put this in an SSDT just for grins, but it can also go in the DSDT.
-- ciao, al
Al Stone Software Engineer Linaro Enterprise Group al.stone@linaro.org
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
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
On 06/18/2013 08:48 AM, Linus Walleij 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).
Right -- and in the Arndale code, they've got these two all munged together in funny ways.
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.
Aha. A precedent -- I like that :).
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
I have not scanned LKML for this patch (yes, I'm being lazy). Would you mind forwarding a copy?
Thanks, Linus.