Messages in this thread | | | Date | Fri, 09 Nov 2012 17:05:41 +0200 | From | Mathias Nyman <> | Subject | Re: [PATCH 1/3] gpio / ACPI: add ACPI support |
| |
On 11/09/2012 04:18 PM, Grant Likely wrote: > On Fri, Nov 9, 2012 at 2:11 PM, Mathias Nyman > <mathias.nyman@linux.intel.com> wrote: >> On 11/08/2012 09:38 PM, Mika Westerberg wrote: >> ... >> >>>>> +#include<linux/errno.h> >>>>> +#include<linux/gpio.h> >>>>> +#include<linux/module.h> >>>>> +#include<linux/acpi_gpio.h> >>>>> +#include<linux/acpi.h> >>>>> + >>>>> +static int acpi_gpiochip_find(struct gpio_chip *gc, void *data) >>>>> +{ >>>>> + acpi_handle handle = data; >>>>> + acpi_handle gc_handle; >>>>> + >>>>> + if (!gc->dev) >>>>> + return false; >>>>> + >>>>> + gc_handle = gc->dev->acpi_handle; >>>>> + if (!gc_handle) >>>>> + return false; >>>> >>>> >>>> This test is redundant with the next one... unless 'handle' is also NULL >>>> :-) >>>> >>>> Is it at all possible for multiple gpiochips to be used for a single >>>> ACPI gpio controller node? Such as if the gpio controller has multiple >>>> banks that should be controlled separately? If so then this won't be >>>> sufficient. I've got the same issue with DT support where the find >>>> function needs to also check if the pin is provided by that specific >>>> gpiochip. >>> >>> >>> AFAIK no but I'll let Mathias to answer that as he knows this better. >> >> >> I'm interpreting it the same way as Mika, max one actual controller per ACPI >> device node >> >> The path (called ResourceSource in ACPI5 specs) in GpioIO/GpioInt resources >> is a "string which uniquely identifies the GPIO controller referred to by >> this descriptor." The pin number is zero based controller relative. >> >> The ACPI device controller node includes all other resources needed by the >> controller driver (ioport/mem base, range, interrupt, and Hardware ID used >> to pair with a driver) >> >> Checked a board with two identical gpio controllers on it and it had two >> separate ACPI device node entries. (with only different io address base and >> interrupt resources) > > That's not really the situation that I'm thinking about. What I mean > is for a gpio controller that is more convenient for Linux to support > using multiple gpiochips (Linux internal detail), even though there it > is described with a single ACPI node. >
Ok, now I get it.
Yes, in case a driver uses several gpiochips internally for different banks of a controller then all would have the same acpi_handle. acpi_get_gpio() would use the gpiobase of the first gpiochip that matches the handle, even if it's the wrong one.
I guess It's possible to write a driver like that. The only acpi enumerated driver with the acpi_handle set (soon coming to upstream) is not done like that.
Do you think this is a case that should be solved now? or just expect acpi gpio device driver to not use several gpiochips in one driver?
-Mathias
| |