Re: [PATCH 0/3] pinctrl: Align Cannon Lake GPIO number space with Windows

[Linus Walleij]

On Mon, Nov 27, 2017 at 2:54 PM, Mika Westerberg
<mika.westerberg@xxxxxxxxxxxxxxx> wrote:

> It turns out that the Cannon Lake GPIO driver in Windows uses different
> GPIO numbering scheme than what Linux uses. Instead of hardware numbers it
> has "banks" of 32 pins even if the hardware group actually does not have
> that many pins. This is problematic for Linux because BIOS uses the same
> Windows numbering scheme in ACPI GpioIo/GpioInt resources, making Linux to
> pick a wrong pin.
>
> For example the SD card detection GPIO resource in BIOS ACPI tables looks
> like:
>
>   GpioInt (...) {231} // vSD3_CD_B
>
> Where the real hardware number would be 180 instead of 231.
>
> Unfortunately changing the BIOS and the Windows driver is not possible for
> Cannon Lake anymore so we need to handle it in Linux instead. This should
> be done properly in future platforms.
>
> The patch series updates the Intel pinctrl driver to allow passing custom
> GPIO number space, taking advantage of pin ranges supported by the pinctrl
> core. However, before we can add these pin ranges we need to drop the
> custom Cherryview GPIO/ACPI translation first and make the driver to use
> direct mapping instead (which turns out to be much simpler).
>
> Once that is done we update the Cannon Lake pinctrl driver to align with
> the Windows GPIO driver numbering scheme.
>
> Mika Westerberg (3):
>   gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation
>   pinctrl: intel: Allow custom GPIO base for pad groups
>   pinctrl: cannonlake: Align GPIO number space with Windows

I applied these with Andy's ACKs.

I guess I vageuly understand what happened.

So the ACPI GPIO numberspace was misaligned with the
actual hardware GPIO numberspace. That's unfortunate.

I hope these is nothing in here trying to align the *LINUX*
global GPIO numberspace with this weirdness and that
lsgpio still gives something reasonable per-gpiochip?

Yours,
Linus Walleij