Re: [PATCH 1/4] gpio / ACPI: Add knowledge about pin controllers to acpi_get_gpiod()

[Linus Walleij]

On Wed, Oct 29, 2014 at 11:27 AM, Mika Westerberg
<mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> On Wed, Oct 29, 2014 at 10:41:19AM +0100, Linus Walleij wrote:

>> But I have a vague idea that there is something like a numberspace
>> concept inside ACPI as well, and that is all magic to me...
>> mixing that into this is a bit scary to me.
(...)
>         # grep SATA_GP1 pins
>         pin 76 (SATA_GP1) mode 1 ctrl0 0x00010200 ctrl1 0x04c00000
>
>         # cat gpio-ranges
>         GPIO ranges handled:
>         0: INT33FF:00 GPIOS [456 - 463] PINS [0 - 7]
>         8: INT33FF:00 GPIOS [464 - 471] PINS [15 - 22]
>         16: INT33FF:00 GPIOS [472 - 479] PINS [30 - 37]
>         24: INT33FF:00 GPIOS [480 - 487] PINS [45 - 52]
>         32: INT33FF:00 GPIOS [488 - 495] PINS [60 - 67]
>         40: INT33FF:00 GPIOS [496 - 503] PINS [75 - 82]
>         48: INT33FF:00 GPIOS [504 - 511] PINS [90 - 97]
>
> In other words GPIO number for pin 76 is 496 (in Linux global number
> space) and 41 in the GPIO driver local number space.
>
> In order to translate the ACPI GPIO number 76 to the right GPIO number
> we iterate over each range in the GPIO driver and look for the match.
> Note that it actually uses the local number (41) here:

OK what I was mainly worrying about was that it would go and
use the Linux GPIO numbers in any way. As long as the mechanism
relies on the local pin controller or GPIO chip offsets I'm happy.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/